Stackable Release 25.3.0

Release checklists

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

General Pre-Requisites (before Feature Freeze)

Early Pre-release tasks

• Create a "Release Retro" issue (linked in "post release tasks")
• Define product versions to include in the next release
• chore: Update and release workspace members operator-rs#970
• chore(tracking): Pre-release updates for Stackable Release 25.3.0 operator-templating#484
• chore(tracking): Update Rust dependencies of operators before SDP Release 25.3.0 #699
• chore: Major or Minor Container Images updates for Stackable Release 25.3.0 docker-images#964
• Patch Container Images updates Doing as part of the step above
• chore: Update Rust dependencies PR template operator-templating#487

Pre-release

• Run all of the test suites in Jenkins (with all product versions, not just "nightly")
• chore(tracking): Check and update getting-started scripts before SDP Release 25.3.0 #697
• chore(tracking): Update Helm charts for 25.3.0 demos#156
• chore(tracking): Test demos on nightly versions for 25.3.0 demos#157
• Ensure integration tests are successful on OpenShift Skipped
• Check stackable-utils scripts in dry-run mode work

Other Pre-Requisites (before Feature Freeze)

Search for open issues labeleded with scheduled-for/25.3.0

Other release-specific pre-requisites

• Run niv update and test via make run-dev (operator-templating) Skipping this due to time

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

• 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 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 for the Release Candidate
• Test demos and upgrade from previous to this release 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)
• chore: Add 25.3.0 release crddocs#50
• Test stackablectl with locally updated (to new release number) releases.yaml
• chore: Add 25.3 release with 25.3.0 images release#36
• chore(tracking): Check and update getting-started scripts for SDP Release 25.3.0 #704
• chore(tracking): Test demos for 25.3.0 demos#187
• 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 (defer aarch64 until interu is used)) @NickLarsenNZ
• Initiate OpenShift testing (run with --test-suite openshift against Replicated OKD)
• OCP Helm/stackablectl testing #709

Documentation tasks

• Create a stackabletech/documentation branch called docs/release-notes-25.3.0
• Compile list of new product features in newly supported versions for the 25.3.0 release #705
• chore(tracking): Release Notes for SDP 25.3.0 documentation#723
• Update SDP release version in documentation/modules/ROOT/pages/getting-started.adoc and test the release install command @NickLarsenNZ
• Cut a release branch (see scripts/make-release-branch.sh) Use release-25.3 instead of release/25.3.
• 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 (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 Already done before the docs branch was cut
• chore: Release stackablectl 25.3.0 stackablectl#367

Marketing tasks can now reference published documentation.

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
• Send announcement to Heise
• Ping the stackable-ionos-tech channel or anyone responsible once all tags are created

Post-release tasks

• At this point, we could do 24.11->25.3 demo upgrade testing that was removed from chore(tracking): Test demos for 25.3.0 demos#187
• Update the list of supported SDP releases in Jira (ping Jim)
• Openshift certification. Create an issue from this template for the OLM manifests OLM Manifests for SDP Release 25.3 #714
• chore: Mark 23.11 as end-of-life documentation#726
• Post 25.3.0 release retro: Release Retro 25.3.0 #694
• chore(issue_template): Post 25.3.0 updates #710
• Create the next release tracking task (Done in chore(tracking): SDP Release 25.7.0 #722)
• https://github.com/stackabletech/infrastructure/pull/246