After the 24.11 release, we will hold a release-retro to discuss what went well, and find out where we can improve.
The task list below can capture items as we think of them.
### Retro items and issues
- [ ] Consider aarch64 testing (we didn't do it this time, but did on 24.7)
- [ ] https://github.com/stackabletech/stackable-utils/issues/82
- [ ] Consider product upgrade integration tests (see https://github.com/stackabletech/hive-operator/pull/539)
- [ ] Consider operator-upgrade integration tests (think about the assertions)
- [ ] https://github.com/stackabletech/stackable-utils/issues/81
- [ ] Improve the "big" demo so that spark waits until the Kafka topics have been created by NiFi.
- [ ] https://github.com/stackabletech/nifi-operator/issues/647
- [ ] Add issue template for the technical release tasks in the issues repo
- [ ] Make demo images versioned (see TODOs in https://github.com/stackabletech/demos/pull/132)
- [ ] Add slack notifications to the demo image build workflows
- [ ] stackable-utils scripts should check all dependecies are satisfied before running
- [ ] https://github.com/stackabletech/docker-images/pull/936
- [ ] We might be rate limited by Maven. Would sure be nice to have a pull-through cache.
- [ ] Print out Git author details in stackable-utils script to make sure it is correct (waiting for confirmation)
- [ ] 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
- [ ] Discuss usage of labels and how each of us use them (consider end-user labels vs developer labels)
- [ ] 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
- [ ] Something something CI infrastructures failures (Omid stuck)
- [ ] Automate the arch package update for stackablectl
- [ ] The issue templates with instructions really paid off. Lowered the cognitive load and allowed us to more easily distribute work
- [ ] 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)
- [ ] Make maven output more quiet in docker-images
- [ ] 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)
- [ ] Assert that the right image index manifest for product images (docker-images) is pushed during release
- [ ] On release, we should update the tools and testing-tools image tags in the kuttl tests and getting_started manifests.
- [ ] releases repo automation (see: https://github.com/stackabletech/release/pull/34#pullrequestreview-2448184263)
- [ ] stackablectl op install should know to install commons/secret/listener operators before others to save additional restarts of products
- [ ] Get quick secobserve stats between releases for the release-notes
- [ ] 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.
- [ ] 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
- [ ] The Release process and templates done after 24.7 were super helpful and made the first half of the release far easier.
- [ ] Automate image mirroring for Quay.io
- [ ] The last minute issue (airflow?) also see https://github.com/stackabletech/issues/issues/630
After the 24.11 release, we will hold a release-retro to discuss what went well, and find out where we can improve.
The task list below can capture items as we think of them.