chore(issue_template): Post 25.3.0 updates (#710)

* chore(issue_template): Update template links

* chore(issue_template): Add info in post release task

* chore(issue_template): Add additional milestones

* chore(issue_template): Update task lists based on #686

Author: NickLarsenNZ

.github/ISSUE_TEMPLATE/06-release.md

@@ -18,7 +18,10 @@ assignees: ''
 > Important dates:
 > - ... - Release planning
 > - ... - Lock product versions
-> - ... - Target release date
+> - ... - Final operator-rs release at CoB
+> - ... - Begin bumping operator-rs crates in each operator
+> - ... - Begin release-day tasks (release branches are cut)
+> - ... - Target release date (marketable)
 
 ## Release checklists
 
@@ -31,11 +34,11 @@ Replace the items in the task lists below with the applicable Pull Requests / Is
 
 ```[tasklist]
 ### Early Pre-release tasks
-- [ ] [Create a "Release Retro" issue](https://github.com/stackabletech/issues/issues/new?template=release-retro.md)
+- [ ] [Create a "Release Retro" issue](https://github.com/stackabletech/issues/issues/new?template=08-release-retro.md)
 - [ ] 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)
+- [ ] [Update Rust dependencies of operators](https://github.com/stackabletech/issues/issues/new?template=05-pre-release-operator-rust-deps.md)
 - [ ] [Major or Minor Container Images updates](https://github.com/stackabletech/docker-images/issues/new?template=early-pre-release.md)
 - [ ] [Patch Container Images updates](https://github.com/stackabletech/docker-images/issues/new?template=early-pre-release.md)
 ```
@@ -46,10 +49,10 @@ Replace the items in the task lists below with the applicable Pull Requests / Is
 ```[tasklist]
 ### Pre-release
 - [ ] Run all of the test suites in Jenkins (with all product versions, not just "nightly")
-- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=pre-release-getting-started-scripts.md)
+- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=03-pre-release-getting-started-scripts.md)
 - [ ] [Check and update demo charts](https://github.com/stackabletech/demos/issues/new?template=pre-release-chart-updates.md)
 - [ ] [Test demos and upgrade from stable to nightly release](https://github.com/stackabletech/demos/issues/new?template=pre-release-upgrade-testing.md)
-- [ ] Ensure integration tests are successful on OpenShift
+- [ ] Ensure integration tests are successful on OpenShift (run with `--test-suite openshift` against Replicated OKD)
 - [ ] Check stackable-utils scripts in dry-run mode work
 ```
 
@@ -70,22 +73,24 @@ 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 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 branch for demos (see stackable-utils for script to create branches)
+- [ ] _Wait for images to be built_
+- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md) for the Release Candidate
+- [ ] [Test demos and upgrade from previous to this release](https://github.com/stackabletech/demos/issues/new?template=release-upgrade-testing.md) for Release Candidate (only fresh install)
+- [ ] Create release tag(s) for docker-images (see stackable-utils for scripts to create tags)
 - [ ] 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)
 - [ ] 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 and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=release-getting-started-scripts.md)
+- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md)
 - [ ] [Test demos and upgrade from previous to this release](https://github.com/stackabletech/demos/issues/new?template=release-upgrade-testing.md)
 - [ ] Check that an upgrade can be performed on an existing cluster without data loss (cycling demo)
-- [ ] Run all integration tests (for both `x86_64` and `aarch64`)
-- [ ] OpenShift testing (discuss internally)
+- [ ] Run all integration tests (for both `x86_64` and ~`aarch64`~ (defer aarch64 until interu is used))
+- [ ] Ensure integration tests are successful on OpenShift (run with `--test-suite openshift` against Replicated OKD)
+- [ ] Release stackablectl
 ```
 
 > [!TIP]
@@ -96,12 +101,14 @@ This will not be so crucial with release branches, but is nonetheless sensible a
 ```[tasklist]
 #### Documentation tasks
 - [ ] Create a stackabletech/documentation branch called `docs/release-notes-YY.M.X`
+- [ ] Compile list of new product features in newly supported versions for the YY.M.X release (for the blog post)
 - [ ] Begin writing the release notes with the [Pull Request template](https://github.com/stackabletech/documentation/compare/main...docs/release-notes-YY.M.X?template=release-notes.md&title=chore(tracking):%20Release%20Notes%20for%20SDP%20YY.M.X)
-- [ ] Update SDP release version in documentation/modules/ROOT/pages/getting-started.adoc and test the release install command
+- [ ] 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))
+- [ ] Remove any references to HEAD and main from the Antora playbooks on the release branch (replace with the release branch)
 - [ ] 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?)
+- [ ] Set the release to "Released" in the Feature Tracker and create a new release (ping @lfrancke)
 - [ ] 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
 ```
 
@@ -128,9 +135,11 @@ Marketing tasks can now reference published documentation.
 
 ```[tasklist]
 #### Post-release tasks
+- [ ] Test demo upgrades, which were skipped in the previous testing (optional)
 - [ ] Update the list of supported SDP releases in Jira (ping Jim)
 - [ ] 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
-- [ ] 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.
+- [ ] Mark any releases older than one year as "end-of-life" [in the documentation](https://github.com/stackabletech/documentation/blob/f751e7ff7cddacae7d2c6c2c6c1d1c877c7aa11c/antora.yml#L18) (update antora.yaml on the applicable branches).
 - [ ] Post YY.M.X 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)
+- [ ] Update the release tracking template (optional)
+- [ ] [Create the next release tracking task](https://github.com/stackabletech/issues/issues/new?template=06-release.md) (if the date is available)
 ```