Early Pre-release tasks

• Create release and release-retro labels if not already present
• Create a "Release Retro" issue: Release Retro 26.3.0 #813
• Define product versions to include in the next release
• chore(tracking): Update major/minor versions for 26.3.0 docker-images#1368
• chore(tracking): Update patch versions for 26.3.0 docker-images#1414

Pre-release

• tracking: Update and release workspace members for SDP 26.3.0 operator-rs#1155
• tracking: Pre-release updates for SDP 26.3.0 operator-templating#575
• tracking: Update operator images to ubi10 operator-templating#579
• tracking: Bump Rust dependencies of operators for SDP 26.3.0 #825
• Run all of the test suites in Jenkins (with all product versions, not just "nightly") @NickLarsenNZ
• tracking: Check and update getting-started scripts before SDP Release 26.3.0 #826
• tracking: Update Helm charts for 26.3.0 demos#368
• tracking: Test demo upgrades on nightly versions for 26.3.0 demos#371
• tracking: Test demos on nightly versions for 26.3.0 demos#372
• Ensure integration tests are successful on OpenShift (run with --test-suite openshift against Replicated OKD)
• Check stackable-utils scripts in dry-run mode work
• Search for open issues labeled with scheduled-for/26.3.0

Release branching

• Create release branch for docker-images
• Create release branches for operators
• Create release branch for demos
• Wait for images to be built before proceeding

Release candidate testing

We've decided to use this stage to test CI workflows rather than test operators/products (as that has been done).
This was also supposed to be a way to test that the product images are available (instead of relying on old versions with 0.0.0dev). But any incorrect refs can be updated on the release branch and likely wouldn't require retagging.

Release tagging

• Create release tag(s) for docker-images
• Create release tag(s) for operators
• Update release version in changelogs on main branches
• Wait for images to be built before proceeding
• Test stackablectl with locally updated (to new release number) releases.yaml
• Update release.yaml: chore: Add 26.3.0 release release#40
• chore(stackablectl): Release 1.3.0 stackablectl#431

Release verification

• tracking: Check and update getting-started scripts for SDP Release 26.3.0 #831
• tracking: Test demos on nightly versions for 26.3.0 demos#392
• Check that an upgrade can be performed on an existing cluster without data loss (cycling demo) @NickLarsenNZ
• Run all integration tests (for both x86_64 and aarch64 (defer aarch64 until interu is used)) @NickLarsenNZ
• Ensure integration tests are successful on OpenShift (run with --test-suite openshift against Replicated OKD)

Documentation tasks

• chore: Add 26.3.0 release crddocs#56
• Create a stackabletech/documentation branch called docs/release-notes-26.3.0
• Compile list of new product features in newly supported versions for the 26.3.0 release (for the blog post)
• tracking: Release Notes for SDP 26.3.0 documentation#828
• chore: Update getting-started release version to 26.3.0 documentation#830
• Cut a release branch (see scripts/make-release-branch.sh)
• Update releases in the playbook (see 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 (ping @lfrancke)
• Update the getting-started page in the main docs and check it works with this release

Marketing tasks

• Write marketing / customer oriented release summary to be published in the marketing channels
• Update the homepage banner (as long as we have it) to point to the new release
• Write a blogpost / news article announcing the new release (optional)
• Write a description of new demos for homepage/demos section
• Announce Release on LinkedIn
• Announce Release in Newsletter (optional)
• Produce a release highlight video (optional)
• Announce Release on Hacker News (optional)
• 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
• Post an announcement in Discord
• Post an announcement on DOK Community in the #be-shameless Channel (Ping Lars or Jim)
• Post an announcement via OSBA (Ping Lars, mailto:[email protected])
• Send announcement to Kubernetes Podcast (Ping Lars)
• Send announcement to Heiser
• Ping the stackable-ionos-tech channel or anyone responsible once all tags are created

Post-release tasks

• Test demo upgrades, which were skipped in the previous testing (optional)
• Update the list of supported SDP releases in Jira (ping @Jimvin)
• chore(tracking): OLM Manifests for SDP Release 26.3.0 #834
• Mark any releases older than one year as "end-of-life" in the documentation (update antora.yaml on the applicable branches).
• Link to release retro issue (use issue created at the start of the process)
• Update the release tracking templates (optional)
• Create the next release tracking task (if the date is available)