Auto-merge between release branches
Bugs and security fixes often need to be added to multiple branches, either back porting fixes to old releases, or fixing an issue in
master and pending release branches that have already been branched. This can be done manually, but it is laborious and error prone. GitLab should make releasing fixes easy.
- When you do a production hotfix to a release branch, GitLab will attempt to auto-merge to newer release branches, and also back to the development branch.
- This will will ensure that any urgent fixes (bugs, major regressions, security patches) are merged to ongoing development work.
- For example, suppose release 1.0 is already in production and there is a major bug discovered. The team does a production hotfix to the branch and releases it. But there are already subsequent branches, 1.1, 1.2 that are currently undergoing final QA and getting ready to be deployed. Always, there is an ongoing mainline development branch. That production hotfix should be merged to those branches.
- GitLab will make the best attempt to merge that change across those branches. Whether they succeed or fail (due to a merge conflict), there will be an indication.
- The mechanism is triggered by the merge request being merged into to a release branch. Upon that merge request being merged, GitLab will make the attempts on the other subsequent branches. The results (succeed or failure) will be logged as system notes in that merge request.
- To know which are release branches and which are newer release branches, we will follow a naming convention. (In future iterations, we may consider making explicit associations. But naming conventions should suffice for now.) Use semantic versioning to indicate newer release branches. (I.e. https://semver.org). A branch is considered a release branch if it has
releasein it's name. And the main development branch is
- This is feature that is configured as a setting in the project settings.