[Proposal] Branching Strategy
Split out from my overall versioning proposal here: https://gitlab.com/charts/gitlab/issues/473
Related to the versioning proposal: https://gitlab.com/charts/gitlab/issues/475
Proposal
For this chart, we propose to follow the same branching strategy as the other main GitLab components.
- A
master
branch, -
x-x-stable
branches that we create from master per minor release. -
x.x.x
tags from those stable branches.
The difference between our branch names, and the other GitLab components, is that we will be using the chart's version in the branch name, rather than the GitLab version.
In general, changes will be merged to master, then cherry-picked into the appropriate branch before release. GitLab image updates will happen as commits in the branches, not in master, as master will follow the latest daily images.
Example timeline of release actions
Related to releasing using the proposed branching strategy
Branch | Tag | Action | Details |
---|---|---|---|
0-2-stable |
Branch | Branch created from master | |
Image update | GitLab 11.0.0-rcX image used |
||
Pick | Additional changes from master picked into branch | ||
Image update | GitLab 11.0.0 image used |
||
0.2.0 |
Tag | Chart 0.2.0 released |
|
Pick | Fixes from master picked into branch | ||
Image update | GitLab 11.0.1 image used |
||
0.2.1 |
Tag | Chart 0.2.1 released |
|
0-3-stable |
Branch | Branch created from master | |
Image update | GitLab 11.1.0-rc1 image used |
||
0-2-stable |
Image update | GitLab 11.0.2 image used |
|
0.2.2 |
Tag | Chart 0.2.2 released |
|
0-3-stable |
Pick | Fixes from master picked into branch | |
Image update | GitLab 11.1.0 image used |
||
0.3.0 |
Tag | Chart 0.3.0 released |
Previous description
Initial discussion options brought up for branching
Options include
- Stay on master
- This requires us to always build with the newest GitLab tag (but not latest), and ignore RC releases
- We can release charts for the latest gitlab patches, and also our own fixes
- We cannot release charts with security patches from a previous GitLab version
- Unless we add some logic so GitLab patches trigger a release using a headless branch based on their previous chart tag
- We would need some sort of CI that was still testing against latest images, to know that it would be even possible to release on the 22nd
- GitLab patch releases, would end up also included new chart features.
- Unless we did the headless branch based on previous tag
- Does not require any manual merging or cherry-picking
- Have a master branch and a stable branch
- Master remains as is, testing against latest
- Stable becomes what we release out of
- Always building the latest GitLab tag and ignore RC releases
- We cannot release charts with security patches from a previous GitLab version
- Unless we add some logic so GitLab patches trigger a release using a headless branch based on their previous chart tag
- Some sort of new process for merging and cherry picking changes from master needs to go into place
- The timing of the merge from master to stable for a new minor release is tight, you need to do it before the GitLab release is tagged, but after the last patch you want for the previous release
- Have a master branch, and a stable branch for every gitlab minor release
- Master remains as is, testing against latest
- We can release security patches for older GitLab versions
- Easily support releasing RCs
- Matches more with other release practices at GitLab in terms of merging and cherry-picking
- Requires manual work in cherry-picking chart fixes from master
- The manual merge from master to the stable branches can happen anytime before the final release is tagged, regardless of other releases going on
I'm still mulling over my opinions on the different options, weight pros and cons. But I will say now that I don't think 2
is great. It includes a new process that is unlike other GitLab products, and manual merge has to happen at a very specific timeframe. So I think either 1.
or 3.
are our best options.