Release branching strategy proposal

[ctron]

Moving towards a release, we should decide on a release branch strategy.

Structure

We create "z-stream" release branches and tag every release. For example:

• main (branch)
  • v0.3.0-alpha.1 (tag)
  • v0.3.0-alpha.2 (tag)
• release/0.1.z (branch)
  • v0.1.0 (tag)
  • v0.1.1 (tag)
• release/0.2.z (branch)
  • v0.2.0 (tag)

Details

During the development of the next version, we create pre-release versions. Just as we do it now.

At some point, before the final release, we create a release branch, which we continue to use for any patch releases (.z).

Each release will be tagged. The release is built from the tag.

The UI and Helm chart repository repository will do the same. The UI dependency in the trustify repository will be switched from main to the "release" branch, which would be publish/release/0.1.z.

[desmax74]

The Helm-chart and the trustify-ui and the Ansible playbook aren't following the same cadence and versions due to the different rate of updates/releases

[ctron]

True. I'd expect them to have the same release branch. But they might actually have different tags.

[mrizzi]

Overall I agree with everything you wrote about the branching strategy.

I just want to highlight a difference with the current approach applied in trustification so far so that a better informed decision can be taken.

Currently the tag is applied after the release to the commit the released artifacts were built from since currently builds are commit-triggered rather than tag-triggered.
Basically the commit that made it successfully through QE tests will be tagged with the version value keeping us free from having to remove a tag when it fails QE tests.

[ctron]

Ah, good point. Yes, I think that makes perfect sense. I'll update the initial comment in this discussion accordingly.

[ctron]

Hm, updating the comment, I stumbled over the following issue with that approach:

The QE process is a Red Hat thing. The tag is actually an upstream thing. I know that today, there isn't much of a difference. But let's consider this at least.

I think two parts play into this: 1) the red hat release process 2) a possible midstream repository.

1. If we consider the RH release process, then it might be appropriate to apply a -redhat tag to the released commit. We can have both upstream and downstream releases with different tags. I think I saw this before: v1.0.0 vs v1.0.0-redhat-0001.

2. If we end up having a midstream repository, having branding and such applied before the build. Then we'd need to tag commits on this repository anyway. And not in the upstream repository. So having -redhat tags would work the same way and indicate the difference between upstream and downstream.