chore: improve the release task list with more explicit steps

[NickLarsenNZ]

Some of the tasks were too vague, and were done out of order.
This change should help improve the process for the next release.

Part of #632

---

Preview of release.md - 7ed5a81

Stackable Release XX.(X)X

[!IMPORTANT]
Important dates:

• ... - Release planning
• ... - Target release date

Release checklists

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

General Pre-Requisites (before Feature Freeze)

Week 1

Preview Give feedback

1. Update and release operator-rs workspace members
2. Update Rust toolchain of operators
3. Update Rust dependencies of operators
4. Update Container Images

Week 2

Preview Give feedback

1. Check and update getting-started script
2. Test and update demos stable to nightly
3. Ensure integration tests are successful on OpenShift
4. Test SDP release upgrade against several demos (i.e. install current release, run demo, bump to dev release, check what needs to be patched)
5. Run all of the test suites in Jenkins (with all product versions, not just "nightly")

Other Pre-Requisites (before Feature Freeze)

Search for open issues labeleded with scheduled-for/20XX-X

Other release-specific pre-requisites

Preview Give feedback

1. ...

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

Preview Give feedback

1. Create release branches for docker-images (see stackable-utils for script to create branches)
2. Create release tag(s) for docker-images (see stackable-utils for scripts to create tags)
3. Create release branches for operators (see stackable-utils for script to create branches)
4. Create release tag(s) for operators (see stackable-utils for scripts to create tags)
5. Create release tag for stackable-cockpit (optional, highly experimental, requires manual tag creation)
6. Update changelogs in main branches (see stackable-utils for script to do this)
7. Generate CRD docs website for the new release by following these instructions
8. Check (selected) integration tests
9. Check getting started scripts (use a table in Nuclino)
10. Run/check getting-started scripts
11. Run/check demos with dev release and main branch and create draft PR for release-related changes
12. Test with locally updated (to new release number) releases.yaml
13. Update release.yaml in https://github.com/stackabletech/release/blob/main/releases.yaml
14. Check that an upgrade can be performed on an existing cluster without data loss.
15. Run all of the test suites

Documentation tasks

Preview Give feedback

1. Check the Changelog and/or issue labels to compile Release Highlights
2. Upgrade guide: Document how to use stackablectl to uninstall all and install new release
3. Upgrade guide: Document how to use helm to uninstall all and install new release
4. Upgrade guide: Every breaking change of all our operators
5. Upgrade guide: List dropped supported product versions (if there are some)
6. Upgrade guide: List dropped supported operators (if there are some)
7. Upgrade guide: List supported k8s versions
8. Update version of main documentation repo
9. Set the release to "Released" in the Feature Tracker and create a new release
10. 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

Marketing tasks can now reference published documentation.

Marketing tasks

Preview Give feedback

1. Write marketing / customer oriented release summary to be published in the marketing channels
2. Update the homepage banner (as long as we have it) to point to the new release
3. Write a blogpost / news article announcing the new release (optional)
4. Write a description of new demos for homepage/demos section
5. Announce Release on LinkedIn
6. Announce Release in Newsletter (optional)
7. Produce a release highlight video (optional)
8. Announce Release on Hacker News (optional)
9. 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
10. Post an announcement in Discord
11. Post an announcement on DOK Community in the #be-shameless Channel (Ping Lars or Jim)
12. Post an announcement via OSBA (Ping Lars, info@osb-alliance.com)
13. Send announcement to Kubernetes Podcast (Ping Lars)
14. Send announcement to Heiser
15. Ping the stackable-ionos-tech channel or anyone responsible once all tags are created

Post-release tasks

Preview Give feedback

1. Update the list of supported SDP releases in Jira (ping Jim)
2. Bump Rust version. This can be done in this file by changing rust_version and also for the ubi base image here. Please be aware that this action will change it for all repositories at the same time (when merging the templating PRs).
3. Check/bump versions of kube-rs and k8s-openapi (also checking the version of k8s we build against)
4. Check/bump ubi9 base image
5. preflight now checks automatically it's own version and only runs if latest Check/bump preflight
6. Openshift certification. Create an issue from this template for the OLM manifests
7. Define product versions to include in the next release
8. Add branch protection to release branches once they are stable
9. Mark any older releases that are now end-of-life as such in the documentation (Ping Felix)

[xeniape]

LGTM

[Techassi]

I would like to see some more changes. I can push what I have in mind to this PR if @NickLarsenNZ is okay with that.

[NickLarsenNZ]

I also had an idea to make some more issue templates in repos, and then refer to them in this task list.

That way they won't get too details in a small box.

[Techassi]

I also had an idea to make some more issue templates in repos, and then refer to them in this task list.

That way they won't get too details in a small box.

I like the idea! Then we can keep it simple in this template and add more details in the operator issue template.

Outdated

[adwk67]

Release notes
A comment on compiling the release notes. For 24.7, I compared the individual changelogs with the list of PRs and found the changelogs to be of little/no help:

• some issues that are intentionally omitted from the CLs (e.g. docs) are still useful for highlighting to users (e.g. the production-ready rego rule documentation for Trino and HDFS)
• some things are missed or incomplete (e.g. where a change spans more than one PR, or vice-versa)

It is quicker to run through an (overly) exhaustive list of PRs than to try and merge two different sources of information.
Clearly documented epics are also a great help as they link to the PRs e.g. #594 and stackabletech/demos#59.

[Techassi]

Thanks for the input!

Regarding the changelogs, we had a lot of discussions via direct messages. At this point in time many voices raised issues with the changelogs in general (missing entries, linking to wrong PRs, partial entries, format and spelling errors) and the current workflow around them.

That's why I think it is appropriate to revisit the following decision: https://github.com/stackabletech/decisions/issues/9 which was put on hold. I would also be happy to spend time on coming up with a new workflow, documentation and changes required in our repos to make this approach work.

[Techassi]

LGTM, just one minor nit.

[NickLarsenNZ]

Release notes A comment on compiling the release notes. For 24.7, I compared the individual changelogs with the list of PRs and found the changelogs to be of little/no help:

* some issues that are intentionally omitted from the CLs (e.g. docs) are still useful for highlighting to users (e.g. the production-ready rego rule documentation for Trino and HDFS)

* some things are missed or incomplete (e.g. where a change spans more than one PR, or vice-versa)

It is quicker to run through an (overly) exhaustive list of PRs than to try and merge two different sources of information. Clearly documented epics are also a great help as they link to the PRs e.g. #594 and stackabletech/demos#59.

@adwk67, the product image update templates have Acceptance Criteria for release note text to be provider, and a release-note label to be added if necessary.

Other templates will also need this, and will follow the same idea.