Improve Release Management Process

I'd like to introduce some Release Management features I introduced in the last month into yaook/k8s here as well. So this will be a collection of

• what is currently done in yaook/k8s,
• what is (in my understanding) currently done in yaook/operator and
• what are possible/needed changes in the operator.

[Reference] yaook/k8s

what was there

• basically nothing
• only devel branch with feature-branches
• no tags nor releases
• basically no changelog

what has been introduced

• automatic changelog generation (based on keepachangelog) using towncrier (have a look how it looks now)
• "forcing" developers to place release-notes via a pipeline-job (+ entry in the coding guide)
• automatic versioning (based on semver)
• automatic tagging + gitlab-releases (check out our releases)
• introducion of a branching-modell (with release candidates)
• sidequest: definition on when to run jobs for testing (reduction of overhead)
• policies (versioning, hotfixing, deprecations)
• docs for each release with a banner guiding to the most recent version (see the docs)

yaook/operator

current status

• a vast amount (972 (27.02.24)) of (for an outsider not easy to understand) tags
• no (real) changelog (there are two(!) entries for 4200+ commits)
• most jobs start always (and check within the script, whether to stop) -> needs resources
• branching
  • long-living branches: devel, rolling, stable
  • feature branches
  • releaseprep/{devel|rolling|stable}/..

what I'd like to introduce

• towncrier and the pipeline-job for checking there is a note on a MR
  • the tool is really useful in ensuring to provide a structured, mostly complete changelog for every release
  • the releasenote-files are a perfect base for the version-calculation (-> change tagging-scheme)
  • the in #384 proposed tool reno wasn't usable for our branching-model, but it's using the same mechanism of providing a separate releasenote for every MR and combining them on a release
• versioned docs
• reduce jobs overhead using rules
• use gitlab-releases

discussion

So, to introduce towncrier I currently can not simply copy-paste what has been done in yaook/k8s and that's the starting point for discussions now.

As I understood there are three long living branches (devel, rolling, stable) all getting version-tags when a release process is triggered. From my point of view I would create a changelog for every release, so there would be one for alpha (on devel), for rolling and for base (on stable). Creating a changelog on all releaseprep/..-branches leads to conflicts on the CHANGELOG.md file the next iteration and also to inconsistencies in the changelog.

To circumvent this, there are two options I can come up with:

1. create the changelog (and also the releases) only on one branch (rolling or stable) or
2. change the branching-model.

branching models

In yaook/k8s we decided on a branching model with only one long-living branch (devel) and release-branches. In our release process we create a releaseprep-branch with release-specific changes (version number and changelog) which is tagged as a release-candidate. After one week the releaseprep will be merged into the release-branch (or a new branch is created). (For further explanations see the docs.)

I think it would also easily work with two long-living-branches (devel and stable (instead of the release-branches)) if that would be a compromise, but in this case we would encounter problems at later stages in the release-process (but for now I wanted to start with the first step and not totally overload this issue).

To be honest I'd prefer to use the same model as in TAROOK as in this case I wouldn't have to change much of the other code. But if there are concerns/reasons to stick with the old model I'd be happy to understand them. So: the discussion is open now 😄

I'm also open to a direct meeting if we notice to discuss/explain more.