chore: Interim update to the release template

Author: NickLarsenNZ

.github/ISSUE_TEMPLATE/release.md

@@ -31,6 +31,8 @@ Replace the items in the task lists below with the applicable Pull Requests / Is
 
 ```[tasklist]
 ### Early Pre-release tasks
+- [ ] Create a "Post XX.XX release" retro issue (does this need a template? See https://github.com/stackabletech/issues/issues/669)
+- [ ] Define product versions to include in the next release
 - [ ] [Update and release operator-rs workspace members](https://github.com/stackabletech/operator-rs/issues/new?template=release-workspace-members.md)
 - [ ] [Update Rust toolchain of operators](https://github.com/stackabletech/operator-templating/issues/new?template=pre-release.md)
 - [ ] [Update Rust dependencies of operators](https://github.com/stackabletech/issues/issues/new?template=pre-release-operator-rust-deps.md)
@@ -68,20 +70,22 @@ This will not be so crucial with release branches, but is nonetheless sensible a
 ```[tasklist]
 #### Technical tasks
 - [ ] Temporarily remove branch protection before pushing the release branches/tags
-- [ ] Create release branches for docker-images (see stackable-utils for script to create branches)
+- [ ] Create release branch for docker-images (see stackable-utils for script to create branches)
 - [ ] Create release tag(s) for docker-images (see stackable-utils for scripts to create tags)
 - [ ] Create release branches for operators (see stackable-utils for script to create branches)
 - [ ] Create release tag(s) for operators (see stackable-utils for scripts to create tags)
 - [ ] Create release tag for stackable-cockpit (optional, highly experimental, requires manual tag creation)
 - [ ] Update release version in changelogs on main branches (see stackable-utils for script to do this)
+- [ ] Create release branch for demos (see stackable-utils for script to create branches)
 - [ ] Generate CRD docs [website](https://crds.stackable.tech/) for the new release by following these [instructions](https://github.com/stackabletech/crddocs)
-- [ ] Check (selected) integration tests on the new release branches
-- [ ] Run/Check getting started scripts, ensure image pulls for the release works
-- [ ] Run/Check demos with dev release and main branch and create draft PR for release-related changes
 - [ ] Test `stackablectl` with locally updated (to new release number) `releases.yaml`
 - [ ] Update `release.yaml` in https://github.com/stackabletech/release/blob/main/releases.yaml
-- [ ] Check that an upgrade can be performed on an existing cluster without data loss.
+- [ ] ARM demo and integration testing of some kind
+- [ ] [Check and update getting-started script](https://github.com/stackabletech/issues/issues/new?template=TODO-getting-started-scripts.md)
+- [ ] [Test demos for the new release](https://github.com/stackabletech/demos/issues/new?template=TODO-release-testing.md)
+- [ ] Check that an upgrade can be performed on an existing cluster without data loss (cycling demo)
 - [ ] Run all of the test suites
+- [ ] OpenShift testing on Rosa <!-- where is that at? -->
 ```
 
 ```[tasklist]
@@ -94,9 +98,12 @@ This will not be so crucial with release branches, but is nonetheless sensible a
 - [ ] Upgrade guide: List dropped supported product versions (if there are some)
 - [ ] Upgrade guide: List dropped supported operators (if there are some)
 - [ ] Upgrade guide: List supported k8s versions
-- [ ] Update version of main documentation repo (antora.yml on the release branch)
-- [ ] Update SDP release version in documentation/modules/ROOT/pages/getting-started.adoc
-- [ ] Set the release to "Released" in the Feature Tracker and create a new release
+- [ ] The team reviews the preview release notes: (structure, wording, xrefs and links, sentences on new lines)
+- [ ] Update SDP release version in documentation/modules/ROOT/pages/getting-started.adoc and test the release install command
+- [ ] Cut a release branch (see [scripts/make-release-branch.sh](https://github.com/stackabletech/documentation/blob/main/scripts/make-release-branch.sh))
+- [ ] Update releases in the playbook (see [scripts/publish-new-version.sh](https://github.com/stackabletech/documentation/blob/main/scripts/publish-new-version.sh))
+- [ ] Update antora.yaml version in stackabletech/demos on the release branch - the stackable-utils release-scripts should do this like they do for products and operators.
+- [ ] Set the release to "Released" in the Feature Tracker and create a new release (how?)
 - [ ] Update the getting-started page in the main docs and check it works with this release: https://github.com/stackabletech/documentation/blob/main/modules/ROOT/pages/getting-started.adoc
 ```
 
@@ -124,12 +131,8 @@ Marketing tasks can now reference published documentation.
 ```[tasklist]
 ### Post-release tasks
 - [ ] Update the list of supported SDP releases in Jira (ping Jim)
-- [ ] Bump Rust version. This can be done [in this file](https://github.com/stackabletech/operator-templating/blob/main/config/rust.yaml) by changing `rust_version` and also for the ubi base image [here](https://github.com/stackabletech/docker-images/blob/main/ubi8-rust-builder/Dockerfile#L25). Please be aware that this action will change it for all repositories at the same time (when merging the templating PRs).
-- [ ] Check/bump versions of kube-rs and k8s-openapi (also checking the version of k8s we build against)
-- [ ] Check/bump ubi9 base image
-- [ ] preflight now checks automatically it's own version and only runs if latest ~~Check/bump preflight~~
 - [ ] Openshift certification. Create an issue from this [template](https://github.com/stackabletech/issues/blob/main/.github/ISSUE_TEMPLATE/olm_manifests.md) for the OLM manifests
-- [ ] Define product versions to include in the next release
-- [ ] Add branch protection to release branches once they are stable
-- [ ] Mark any end-of-life releases as such [in the documentation](https://github.com/stackabletech/documentation/blob/f751e7ff7cddacae7d2c6c2c6c1d1c877c7aa11c/antora.yml#L18)
+- [ ] Mark any releases older than one year as "end-of-life" [in the documentation](https://github.com/stackabletech/documentation/blob/f751e7ff7cddacae7d2c6c2c6c1d1c877c7aa11c/antora.yml#L18) How? Ask Lars of course. He's good at that stuff.
+- [ ] Post XX.XX release retro (use issue created at the start of the process)
+- [ ] [Create the next release tracking task](https://github.com/stackabletech/issues/issues/new?template=release.md) (if the date is available)
 ```