Release 2022-11

[lfrancke]

Stackable Release 2022-11

Planned release date is: 2022-11-11

Update/decision 27.10

• Push back feature freeze by a week (to 4.11)
• Implement release branch for one operator 31.10/01.11
• Present findings on 02.11 and plan next steps

Update/decision 07.11

• release branch topic is to be investigated in parallel
• do not update operator-rs (0.25.x) due to breaking changes
• release 22.11 as "normal"

Release process

~We will use a release branch for this release.~ The process can be summarized as follows:

Overview (relevant for release-branch approach i.e. not 22.11)

• Development in short-lived feature branches with PRs merged to main (current practice)
• A release branch is created from main per minor version (e.g. 4.2.x)
• This branch is used for testing and verifying, with fixes being made in main and then cherry-picked to the release branch
• When the release branch is tested and ready, it is tagged and remains open for any subsequent bug fixing etc.

Process steps

• [ ] initiate the release process by creating a release branch e.g. 4.2.x and replace “nightly” etc. (as the current release script does)
• [ ] the docs version is also set, but in antora still marked as prerelease=true
• [ ] conduct a non-formal feature freeze (not technically necessary but not a bad idea either). This branch is now the release-candidate-branch, where tests are made, demos verified etc.
• [ ] test and make changes to code and docs in main and then cherry-picked into the release branch
• [ ] when testing is complete, tag the release branch
• [ ] the docs can now be marked as prerelease=false
• [ ] during the release process, document and plan what can be automated for future releases

Further bug-fixes follow the same pattern (made in main, cherry-picked, release branch re-tagged) A platform release is then defined by the individually released operators at the time of the release plus the stackablectl releases.yaml.

Release checklists

Beginning of the release cycle

• [x] https://github.com/stackabletech/issues/issues/260
• [x] Bump Rust version

Before feature freeze

• [ ] ~Bump operator-rs to latest version in all operators~

Feature freeze

End of the release cycle (Release day)

Technical tasks

• [ ] Bump every operator to the latest operator-rs at some point before the feature freeze (meaning: at least once in the release cycle, and leaving sufficient time for testing etc.)
• [x] Release operators that are part of the release (if release is needed), see separate checklist below
  • [x] Set stable operator versions in the docs/templating_vars.yaml file before releasing, and back to nightly afterwards
  • [x] Release the actual operator
  • [x] Bump the operators to the new -nightly version
• [x] Integration tests passed
• [x] Update stackablectl/release.yaml to add the new release
• [x] Demos updated if required

Documentation tasks

PR for the changelog and upgrade guide: https://github.com/stackabletech/documentation/pull/310

• [x] Create a Changelog including Release Highlights
• [x] Write an upgrade guide
  • [x] Document how to use stackablectl to uninstall all and install new release
  • [x] Document how to use helm to uninstall all and install new release
  • [x] Every breaking change of all our operators
  • [x] List dropped supported product versions (if there are some)
  • [x] List dropped supported operators (if there are some)
  • [x] List supported k8s versions
• [x] Bump documentation
  • [x] Update version of main documentation repo (when it is versioned in the future)

Marketing tasks

• [ ] Update the homepage banner (as long as we have it) to point to the new release
• [x] Write a blogpost announcing the new release (optional) (andrew)
• [ ] ~Produce a release highlight video (optional)~
• [x] Post an announcement in the GitHub Discussions Announcement forum

stackablectl

Actions:

• Bump and test versions used in demos and stacks

stackablectl element	Who	Status
demo: airflow-scheduled-job		:heavy_check_mark:
demo: data-warehouse-iceberg-trino-spark		:heavy_check_mark:
demo: hbase-hdfs-load-cycling-data		:heavy_check_mark:
demo: nifi-kafka-druid-earthquake-data		:heavy_check_mark:
demo: nifi-kafka-druid-water-level-data		:heavy_check_mark:
demo: spark-k8s-anomaly-detection-taxi-data		:heavy_check_mark:
demo: trino-taxi-data		:heavy_check_mark:

Operators

Actions:

• Release
• Test getting started guides
• read/test docs and examples (where relevant)

Operator	Version	Getting started	Examples	Online docs	Blockers	PR
Commons	0.4.0	N/A	N/A	:heavy_check_mark:		112
Secret	0.6.0	N/A	N/A	:heavy_check_mark:	207
(Listener)
OPA	0.11.0	:heavy_check_mark:	N/A	:heavy_check_mark:		370
ZooKeeper	0.12.0	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:		584
Kafka	0.8.0	:heavy_check_mark:	:heavy_check_mark: (logging PR)	:heavy_check_mark:		508
HDFS	0.6.0	:heavy_check_mark:	N/A	:heavy_check_mark:		267
Hive	0.8.0	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:		267
HBase	0.5.0	:heavy_check_mark:	N/A	:heavy_check_mark:		271
NiFi	0.8.1	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:		373
Druid	0.8.0	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:		336
Trino	0.8.0	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:		336
Spark	0.6.0	:heavy_check_mark:	:heavy_check_mark: (with minio patch)	:heavy_check_mark:		173
Airflow	0.6.0	:heavy_check_mark:	:heavy_check_mark:	:heavy_check_mark:		189
Superset	0.7.0	:heavy_check_mark:	:heavy_check_mark: (one yaml deleted)	:heavy_check_mark:		292

[adwk67]

To consider for the release-hackathons:

• check documentation contents are up-to-date with the code
  • check getting-started guides all run
  • check runnable bits of documentation are still working
• move examples into the documentation

[lfrancke]

We should mention in the release notes that the CRD is inconsistent between operators right now and to expect breaking changes.

This refers to the config/tls/authentication changes we discussed today.