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-10-27 - Begin bumping operator-rs crates in each operator
• 2025-11-06 - Begin release-branching tasks (Bumped)
• 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.

• chore: Update and release workspace members for Stackable Release 25.11.0 operator-rs#1111
• chore: Pre-release updates for Stackable Release 25.11.0 operator-templating#555
• chore(tracking): Update Rust dependencies of operators before 25.11.0 #790
• Run all of the test suites in Jenkins (with all product versions, not just "nightly")
  • Most tests succeeded on first try
  • Some failed because of flakiness and were re-run locally to ensure they pass
• chore(tracking): Check and update getting-started scripts before 25.11.0 #791
• chore(tracking): Update Helm charts for 25.11.0 demos#322
• chore(tracking): Test demo upgrades on nightly versions for 25.11.0 demos#326
• chore(tracking): Test demos on nightly versions for 25.11.0 demos#327
• Ensure integration tests are successful on OpenShift (run with --test-suite openshift against Replicated OKD) #793
• Check stackable-utils scripts in dry-run mode work @Techassi
• 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.

• chore(tracking): Check and update getting-started scripts for 25.11.0-rc1 #794
• Selected demo testing
  • logging (25.11.0-rc1 from scratch)
  • end-to-end-security (25.11.0-rc1 from scratch)

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
• chore: Add 25.11.0 release release#39
• Release stackablectl

Release verification

Tip

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

• chore(tracking): Check and update getting-started scripts for 25.11.0 #795
• chore(tracking): Test demos for 25.11.0 demos#336
• 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
• 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.

• chore: Add 25.11.0 release crddocs#54
• Generate CRD docs website for the new release by following these instructions
• Create a stackabletech/documentation branch called docs/release-notes-25.11.0
• chore(tracking): Release Notes for SDP 25.11.0 documentation#797
• Compile list of new product features in newly supported versions for the 25.11.0 release (for the blog post) #797
• 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 Already done above

Marketing tasks

Note

Marketing material can now reference published documentation.

• 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)
• 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 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:
  • chore(tracking): OLM Manifests for SDP Release 25.11.0 #799
  • chore(tracking): update certified operators catalogs #805
• 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)