Early Pre-release tasks

• Create release and release-retro labels if not already present
• Create a "Release Retro" issue
• Define product versions to include in the next release
• tracking: Update major/minor versions for 26.7.0 docker-images#1479
• Patch Container Images updates (Do not reuse the previous issue)

Pre-release

• 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/26.7.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

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

Release verification

• Check getting-started scripts
• Test demos from scratch (26.7.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

• Generate CRD docs website for the new release by following these instructions
• Create a stackabletech/documentation branch called docs/release-notes-26.7.0
• Compile list of new product features in newly supported versions for the 26.7.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

• 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 Heise
• 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).
• Release Retro 26.7.0 #848
• Update the release tracking templates (optional)
• Create the next release tracking task (if the date is available)