Create and implement concept of release branches

[inf17101]

Description

When developing new features and merging pull requests scheduled for the next release into main, then it might be the case that an unexpected bug report of the last release appears and we need to build a new release based on the previous release but including a bug fix.

I have tested successfully our current CI/CD pipeline setup on my private fork to create a release from another branch different to main. This works because our pipeline listens to push tags for a release and checks out the content that is tagged. I verified also that all system tests are executed (it is because the event_type for a tag is "push" and not "pull_request" which leads to executing all stests in the ci/cd).

However, when developing on the release branches directly and not just building a release with a tag, we need to align on the following points and change the ci/cd setup a little bit:

• a common naming convention for release branches, e.g.: release-*, release_*
• branch protection for release branche: yes/no
• adapting the ci/cd setup to execute all necessary tests and pipeline verification steps when pushing to the release branch instead of into main

Goals

A concept for release branches having a common naming convention for branches with all tests and ci/cd steps activated when developing on those branches.

Final result

Summary

To be filled when the final solution is sketched.

Tasks

• Introduce naming scheme for release branches
• Adapt ci/cd pipeline so that all tests and steps are executed when pushing changes to the release branch
• User documentation for creating a release using a release branch

[windsource]

We need to discuss, if we want to include the patch version in the branch name. I think using major and minor version should be sufficient. Then we can use the same branch for all patch releases for the same major/minor version. An example branch name would be then release-0.4.

[windsource]

I think we should not delete release branches and also use PRs for release branches and so we should apply branch protection in my opinion.

[inf17101]

I think we should not delete release branches and also use PRs for release branches and so we should apply branch protection in my opinion.

I would recommend this, because we shall do always proper reviews through pull requests. Pushing directly to a branch has some risks.

[inf17101]

We need to discuss, if we want to include the patch version in the branch name. I think using major and minor version should be sufficient. Then we can use the same branch for all patch releases for the same major/minor version. An example branch name would be then release-0.4.

I think release-0.4 is enough, because the tag already includes the full version and refers to the correct commit hash of this branch if we need multiple minor releases on top.

[inf17101]

Tasks are all done. Issue can be closed.