Automerge to later versions (for easy maintaining release-branches)
Description
When maintaining several releases at a time, there's much work to keep them updated.
Example: Let's have the following branches
- RELEASE/TEST1.8
- RELEASE/TEST2.0
- RELEASE/TEST2.1
- master
now I create a change in a DEV-Branch (DEV/MyBugfix) created from "RELEASE/TEST2.0". Then I create a MR for DEV/MyBugfix --> RELEASE/TEST2.0 I manually have to create 2 more MR
- with destination RELEASE/TEST2.1 and
- with destination master to get the changes there. (For example by Cherry-Pick)
Proposal
It would be great to have a checkbox in the project to enable "auto merge" and a checkbox in each MR to explicitly deactivate the "auto merge" once (for example for special version changing MRs which should not be in newer branches)
When this feature "auto merge" is enabled it would do the following: Automatically merge the changes to RELEASE/TEST2.1 (by a new automatically created merge request) and automatically merge the changes to master (by a new automatically created merge request). Both of those two merge requests will be accepted automatically if there are no conflicts. If there are any conflicts, these will be shown and the MR will stay open so manually fixing and accepting is possible.
Additionally:
- it will NOT automerge to branches with other names and older versions:
- RELEASE/WILLNOTMERGE1.9
- RELEASE/TEST1.8
So the arithmetic to get the branches where the merges have to be done is: The part in front of the number must be the same, the number must be higher. (see semantic versioning) RELEASE/TEST2.1 and master will be merged always. (maybe selectible in the project options - thus could be "DEVELOP" instead of master)
When accepting the merge, there will be a popup which shows to which other branches it will be merged automatically. Here the user can still cancel the MR acceptance - or untick the checkbox for automatic merge of THIS MR.