Release templates updates post 24.11.0

[NickLarsenNZ]

Caution

Depends on:

• Create a release-notes PR template to be used by the release tracking ticket documentation#693
  • fix: Remove frontmatter from release-notes template documentation#694
• chore: Add release-upgrade-testing tracking issue template demos#136

Changes

• Move some post release tasks to early pre-release tasks.
• Move release note procedure to a separate template (Create a release-notes PR template to be used by the release tracking ticket documentation#693).
• Link to getting started pre-release and release tracking issue templates.
• Link to demo testing pre-release and release tracking issue templates.
• Make release placeholders consistent (with YY.M.X (or YY.M)).
• Add/combine/move tasklist items.
• Add a Release Retro issue template.

Preview (3090291)

Stackable Release YY.M.X

[!IMPORTANT]
Important dates:

• ... - Release planning
• ... - Lock product versions
• ... - Target release date

Release checklists

Replace the items in the task lists below with the applicable Pull Requests / Issues

General Pre-Requisites (before Feature Freeze)

[!TIP]
These tasks should be done earlier in the process to lessen the burden at Pre-release time.

Early Pre-release tasks

Preview Give feedback

1. Create a "Post YY.M.X release" retro issue (does this need a template? See Release Retro 24.11.0 #669)
2. Define product versions to include in the next release
3. Update and release operator-rs workspace members
4. Update Rust toolchain of operators
5. Update Rust dependencies of operators
6. Update Container Images

[!TIP]
These tasks should be done a week or so before the release date.

Pre-release

Preview Give feedback

1. Run all of the test suites in Jenkins (with all product versions, not just "nightly")
2. Check and update getting-started scripts
3. Check and update demo charts
4. Test demos and upgrade from stable to nightly release
5. Ensure integration tests are successful on OpenShift
6. Check stackable-utils scripts in dry-run mode work

Other Pre-Requisites (before Feature Freeze)

Search for open issues labeleded with scheduled-for/YY.M.X

Other release-specific pre-requisites

Preview Give feedback

1. Run niv update and test via make run-dev (operator-templating)

Feature freeze

This will not be so crucial with release branches, but is nonetheless sensible as it will make it easier to cherry-pick any release-related bugfixes from main into the release branch.

End of the release cycle (Release day)

Technical tasks

Preview Give feedback

1. Temporarily remove branch protection before pushing the release branches/tags
2. Create release branch for docker-images (see stackable-utils for script to create branches)
3. Create release tag(s) for docker-images (see stackable-utils for scripts to create tags)
4. Create release branches for operators (see stackable-utils for script to create branches)
5. Create release tag(s) for operators (see stackable-utils for scripts to create tags)
6. Create release tag for stackable-cockpit (optional, highly experimental, requires manual tag creation)
7. Update release version in changelogs on main branches (see stackable-utils for script to do this)
8. Create release branch for demos (see stackable-utils for script to create branches)
9. Generate CRD docs website for the new release by following these instructions
10. Test stackablectl with locally updated (to new release number) releases.yaml
11. Update release.yaml in https://github.com/stackabletech/release/blob/main/releases.yaml
12. Check and update getting-started scripts
13. Test demos and upgrade from previous to this release
14. Check that an upgrade can be performed on an existing cluster without data loss (cycling demo)
15. Run all integration tests (for both x86_64 and aarch64)
16. OpenShift testing (discuss internally)

[!TIP]
Name the release-notes branch docs/release-notes-YY.M.X so that the link below takes you directly to the Pull Request template.

Documentation tasks

Preview Give feedback

1. Create a stackabletech/documentation branch called docs/release-notes-YY.M.X
2. Begin writing the release notes with the Pull Request template
3. Update SDP release version in documentation/modules/ROOT/pages/getting-started.adoc and test the release install command
4. Cut a release branch (see scripts/make-release-branch.sh)
5. Update releases in the playbook (see scripts/publish-new-version.sh)
6. 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.
7. Set the release to "Released" in the Feature Tracker and create a new release (how?)
8. 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

Marketing tasks can now reference published documentation.

Marketing tasks

Preview Give feedback

1. Write marketing / customer oriented release summary to be published in the marketing channels
2. Update the homepage banner (as long as we have it) to point to the new release
3. Write a blogpost / news article announcing the new release (optional)
4. Write a description of new demos for homepage/demos section
5. Announce Release on LinkedIn
6. Announce Release in Newsletter (optional)
7. Produce a release highlight video (optional)
8. Announce Release on Hacker News (optional)
9. Post an announcement in the GitHub Discussions Announcement forum and make it a pinned discussion while at the same time removing the old pinned thread
10. Post an announcement in Discord
11. Post an announcement on DOK Community in the #be-shameless Channel (Ping Lars or Jim)
12. Post an announcement via OSBA (Ping Lars, [email protected])
13. Send announcement to Kubernetes Podcast (Ping Lars)
14. Send announcement to Heiser
15. Ping the stackable-ionos-tech channel or anyone responsible once all tags are created

Post-release tasks

Preview Give feedback

1. Update the list of supported SDP releases in Jira (ping Jim)
2. Openshift certification. Create an issue from this template for the OLM manifests
3. Mark any releases older than one year as "end-of-life" in the documentation How? Ask Lars of course. He's good at that stuff.
4. Post YY.M.X release retro (use issue created at the start of the process)
5. Create the next release tracking task (if the date is available)