Release management (git branches and tags)

[snichme]

New major or minor version

When it's time to release a new minor or major version we start by tagging the commit that represent a good point for a new release.
This will become the first rc for the new version.
From this point and until we have released the final version main branch is frozen. No more feature are to be merged into main. This is because we want the changes from the first rc to the final release to be minimal, at most typos as bug fixes that are needed for a stable release.
When the final version has been released we again open up main to allow new features to be merged.

The idea behind this way of working is to ensure a well tested and stable release without any major changes when we have decided that it's time for a new version.
Since no more features are allowed into main during freeze it allows all team members to focus on testing and reviews before the final release.

gitGraph
    commit
    commit tag: "2.6.0-rc1"
    commit
    commit tag: "2.6.0-rc2"
    commit
    commit tag: "2.6.0-rc3" tag: "2.6.0"

Loading

Patch version

If a bug is found in a version that is already released and the next version has already begun on main (for example additional features has been merged into main). Then a new branch is to be created from the tag of the final version.
The bug fix is first introduced into main and then also applied to the bugfix branch created from the tag.
The patch version is then tagged on the branch and will not be merged back into main.

gitGraph
    commit
    commit tag: "2.6.0"
    branch 2.6.x
    commit tag: "2.6.1"
    checkout main
    commit
    commit

Loading

Other ways of working that was considered

Below are the different ways of working that we considered before ending up with the approach described above.

main and release branch

Working on main and merges all PRs into main from PRs.
Check out a release branch make a commit on that branch for 2.6.0-rc1 and tag it.
Continue work on 2.6 on that branch

Pros
Easy to change to
Main always have latest change
Less admin work
Keep main open so we can always merge PRs, as long as they fit the next milestone

Cons
No tags on main, for git describe
You may not get a working version when building from main.

GithubFlow

https://docs.github.com/en/get-started/using-github/github-flow

Main always ready to be deployed. Short branches and hotfixes.
No support for release branches.
Like we do internally.
We might need feature flags.

Cons:
Don't dare to merge to main
Harder to work on versions

GitFlow

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Well tested and documentet
Have tools for it

Cons
Many branches
Getting lost in branches
Need to learn the workflow

OneFlow

https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow

[viktorerlingsson]

One alternative could be to always tag main with the next version whenever we do a rc-version.

So, for example when we release 2.7.0-rc.1, we do that from a 2.7.x branch, and immediately tag main with 2.8.0-dev, so a git describe on main would show that.

Edit: This would be in regards to keep working the way we do now with always merging to main and releasing from release branches.

[carlhoerberg]

if anything i like this the most. ideally i would like our time between rc and sharp release to be shorter. But i recon i'm a big part of the problem, that i'm continuing developing new features instead of stabilizing/testing the beta/rc.