### Retro items and issues
- [x] The last minute issue (airflow?) also see https://github.com/stackabletech/issues/issues/630. How should this be handled in future? Trimmed down template for a patch release?
- [x] Handling last minute bugs and patch releases (immutable tags)
- [ ] https://github.com/stackabletech/stackable-utils/issues/82
- [x] ~Make maven output more quiet in docker-images~
- [x] Assert that the right image index manifest for product images (docker-images) is pushed during release (0.0.0-dev was hard-coded, but never detected until release)
- [x] Add issue template for the technical release tasks in the issues repo
- [x] Have a Post-release template for running getting_started, as there are subtle differences (also the PR template used in the link has `pre` in the name. See https://github.com/stackabletech/issues/issues/672)
- [x] Discuss usage of labels and how each of us use them (consider end-user labels vs developer labels)
- [x] Please add applicable labels to PRs and write release notes... not doing so really makes finalizing the release notes very hard (this could be automated as well, when using conventional commits for PR titles. `!` in the title -> add the label)
- [x] The Release Notes process could be further improved. It still takes a long time, and the work could be parallelized across those responsible for the products
- [x] Release note writing and reviews takes considerable time. Maybe we need a way to indicate this in the release process to set adequate expectations.
- [x] stackable-utils scripts should check all dependecies are satisfied before running
- [x] The release scipts seemed to have missed the templating of the release, so getting_started is deploying 0.0.0-dev (resolved by https://github.com/stackabletech/operator-templating/pull/465)
- [x] Print out Git author details in stackable-utils script to make sure it is correct (waiting for confirmation)
- [x] demos branch creation needs to update the release version, else antora errors occur after docs release time. See: https://github.com/stackabletech/demos/pull/134
- [x] releases repo automation - README version list needs updating (see: https://github.com/stackabletech/release/pull/34#pullrequestreview-2448184263)
- [x] We might be rate limited by Maven. Would sure be nice to have a pull-through cache.
- [x] Something something CI infrastructures failures (Omid stuck with no new output)
- [x] Consider aarch64 testing (we didn't do it this time, but did on 24.7)
- [x] Add slack notifications to the demo image build workflows
- [x] stackablectl op install should know to install commons/secret/listener operators before the actual product operators  to avoid additional restarts of products
- [x] Add _checking the getting started scripts_ in the list of things to check (PR template). This should mean these scripts are more-or-less kept up-to-date (they can take a long time to test and fix if they become stale).
- [x] Consider product upgrade integration tests (see https://github.com/stackabletech/hive-operator/pull/539)
- [x] Consider operator-upgrade integration tests (think about the assertions)
- [x] Improve the "big" demo so that spark waits until the Kafka topics have been created by NiFi. => It should(tm) already do: https://github.com/stackabletech/demos/blob/507d02f30721bc3ea63ebafcbb1b9e5d5162e72c/demos/data-lakehouse-iceberg-trino-spark/create-spark-ingestion-job.yaml#L16
- [x] Last minute nice-to-haves aren't much fun during the technical-release-tasks (eg: https://github.com/stackabletech/stackable-cockpit/pull/336#issuecomment-2483457625) - comment from Sebastian: I opened it and pinged it to the release team if they can include it or not. I did never insist that this should go in :) One could argue a bug-fix is not a nice-to-have, but in this case yes, it was a minor bugfix. Everything is great, I just wanted to give some context
- [x] IMHO we try to bump all tools to the latest support version (even if it's experimental). Reason is that we should try to detect upgrade problems, such as https://github.com/stackabletech/hive-operator/issues/538 or the NiFi 1.27 flows stopping working in 2.0.0
- [x] Get quick secobserve stats between releases for the release-notes
- [ ] https://github.com/stackabletech/nifi-operator/issues/647
- [ ] https://github.com/stackabletech/stackable-utils/issues/81
- [x] Make demo images versioned (see TODOs in https://github.com/stackabletech/demos/pull/132)
- [x] The issue templates with instructions really paid off. Lowered the cognitive load and allowed us to more easily distribute work
- [x] The Release process and templates done after 24.7 were super helpful and made the first half of the release far easier.
- [x] On release, we should pin the tools and testing-tools image tags in the kuttl tests and getting_started manifests.
- [x] Automate image mirroring for Quay.io
- [x] Automate the arch package update for stackablectl
- [x] Props to _Replicated_. It's nice to be able to spin up a cluster, and enter a shell with the kubeconfig already set for the cluster. Also parallelising testing.
- [x] Link checking the docs site (and using xrefs for docs links)
- [x] Broken docs links for latest version (see: https://github.com/stackabletech/documentation/pull/687#issuecomment-2514156355)
- [x] The antora messages are so cryptic (Duplicate alias), and it isn't obvious that we need to remove Page-Aliases from branches. See demo PR (https://github.com/stackabletech/demos/pull/135). This should be automated.
- [x] We improved the image build CI workflows by removing redundant calls to the free-disk-space action https://github.com/stackabletech/docker-images/pull/936
- [x] stackablectl arg on the main stackable website needs updating. How?