Release branching strategies

[rozyczko]

We currently have differing branching strategies for releases, across the projects.

Some (EC, EX, ER) create the pre-release branch off of develop, then merge that branch into master (or main).
Some (ED) only use develop and master and merge (squashed) develop directly into master at release.

The idea with the pre-release branches is that it allows the develop branch to be "live" and constantly updated, without the need to code freeze it while testing the code before release. This is especially valid for teams with developers frequently updating develop.
The additional branch allows for release-specific actions to be performed and "shields" the code from unwanted changes coming from feature branch merges.

However, those pre-release branches introduce extra complexity and need for post-release cherry-picking of changes back to develop.

Additionaly, we often perform commit squashing, when merging into master. This is useful since it makes the history of master clean showing only release related merges (and post-release fixes). However, it seems to cause occasional issues with synchronization of develop <-> master.

Since we are going to rely on templates to create our pipelines, we need to agree on the standard way of branching, hence the poll.

[andped10]

I am in favor of having it as simple as possible (develop -> main). However, I don't know what potential issues that would cause.

As we have talked about the pre-release branch is probably mainly needed if there are very frequent merges to develop. Since such merges in our case mainly would be new features it would probably almost never happen that we will have a collision where new functionality is added to develop while a merge to main is ongoing.

[rozyczko]

Then let's standardize on this option (unless others have different ideas?)