chore(tracking): SDP Release 25.11.0

[labrenbe]

Important

Important dates:

• 2015-07-30 - Release planning
• 2025-09-08 - Lock product versions
• 2025-09-25 - Lock product patch versions
• 2025-10-24 - Final operator-rs release at CoB
• 2025-11-27 - Begin bumping operator-rs crates in each operator
• 2025-11-03 - Begin release-branching tasks
• 2025-11-14 - Target release date (marketable)

Tip

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

Early Pre-release tasks

Tip

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

• Create release and release-retro labels if not already present
• Create taskforce-release-25-11 Slack channel
• Release Retro 25.11.0 #760
• Define product versions to include in the next release
• chore(tracking): Update major/minor versions for 25.11.0 docker-images#1232
• chore(tracking): Update patch versions for 25.11.0 docker-images#1267

Pre-release

Tip

These tasks should be done a week or so before the release date.

• Update and release operator-rs workspace members
• Update Rust toolchain of operators
• Update Rust dependencies of operators
• Run all of the test suites in Jenkins (with all product versions, not just "nightly")
• Check and update getting-started scripts
• Check and update demo charts
• Test demo upgrades (stable to nightly)
• Test demos from scratch (nightly)
• 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/25.11.0

Release branching

Caution

A small change freeze is required until these tasks have been completed.

Tip

See stackable-utils for script to create tags and update changelogs.

• 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

Warning

To be discussed during the on-site.

Getting started scripts use particular product versions (this would have been updated in the
early-pre-release stage), however, at this point in time, the images will be tagged with an rcX
tag.

Release tagging

Tip

See stackable-utils for script to create tags and update changelogs.

• 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
• Release stackablectl

Release verification

Tip

These tasks do not block the Documentation tasks below and can be done concurrently.

• Check getting-started scripts
• Test demos from scratch (25.11.0)
• 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))
• Ensure integration tests are successful on OpenShift (run with --test-suite openshift against Replicated OKD)

Documentation tasks

Tip

Name the release-notes branch docs/release-notes-25.11.0 so that the link below takes you directly to the Pull Request template.

• Generate CRD docs website for the new release by following these instructions
• Create a stackabletech/documentation branch called docs/release-notes-25.11.0
• Compile list of new product features in newly supported versions for the 25.11.0 release (for the blog post)
• Begin writing the release notes with the Pull Request template
• 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)
• 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

Note

Marketing material can now reference published documentation.

• 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:info@osb-alliance.com)
• 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)
• Openshift certification. Create an issue to track the creation of the OLM manifests
• 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)