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?)

[damskii9992]

From a discussion on the easyscience library, added here because it related to all projects:
This comment only concerns when to do merge with or without SQUASH.

develop (SQUASH)

I think that we should always SQUASH when doing merges into develop. Merges into develop will either be the inclusion of a feature branch or a bug fix. For such branches there often are numerous commits to get to the point where the PR was accepted and the new code can be merged in. These commits will in general not be of any interest (in case one wants to have a closer look this can be done by recreating the branch that was merged). To get rid of the "noisy" commits there were made on the branch it should be merged using SQUASH. The result should be a develop branch where each commit (merged PR) either corresponds to the implementation of a feature or the fix of a bug.

pre-release (Not SQUASH)

To progress the pre-release branch all new features / bug fixed from develop should be merged in. In this case the merge should NOT SQUASH because we want to keep the history of the individual commits (features / bug fixes).

master (Not SQUASH)

The same goes when merging to master. In this case we also want to keep the history of the features and bugs and the merge should NOT SQUASH these into a single commit. Furthermore, when keeping the commits it should also be possible to git to resolve the real changes that have happen when comparing the ´develop´, ´pre-release´ and ´master´ branches