The support branch is created in git after every minor release (see Release Process). It has the name in the form:
Where X.Y is the last minor release. This branch is used to group changes for patch releases and maintenance releases.
Fix on Master
Fix the bug on
master, test it, commit and push as usual
master first, support second
Usually all the development work is done on
master or on topic branches that are rebased/merged to
master. This includes bugfixes that should end up in support branch. Everything is fixed in the master branch first and then the patch is backported (cherrypicked) to the support branch. We need to this to make sure that we do not omit any bugfix during the development of the next release. Also the bug might have already been fixed on
master and only needs to be backported. Perhaps the only exception to this method is the case if the bug cannot be fixed on
master, e.g. because the bug is in deprecated code which has already been removed in
master. In such cases the fix may go to the support branch directly.
Checkout Support Branch
To check out the branch as local tracking branch (only needs to be done once):
or just switch to the branch and make sure it is up-to-date
If you get a message "fatal: Cannot update paths and switch to branch 'support-3.5' at the same time" after you have issued the above-mentioned "git checkout --track ..." command, use the "git remote update" command first and then retry the failed operation.
Cherrypick the commit from the
master to the support branch.
Use the commit ID from the master branch as argument. Repeat this if more commits needs to be backported. Mare sure you maintain correct ordering of the cherrypicking. Also have a close look at the commit messages and/or patches of the commits that you are cherrypicking. The code cherrypicked from master may depend on some previous work done on
master that was not cherrypicked to support branch yet. In such case these commits needs to be taken to support branch as well. Alternatively a cherrypick gone bad may be manually fixed with a direct commit to the support branch.
You may get conflicts during the cherry-pick. The
git status command will show the conflicts. The same command will also tell you how to fix them: just open the conflicting files, find where the conflict occured and modify the file to the correct version. The use
git add to mark the conflict fixed. Do this for all the conflicting files. Then continue the cherry-pick with:
git cherry-pick --continue
Please note that the cherrypick is different from a merge. Cherrypick creates new commits (also see reasoning below).
Test and Push
Make sure that the cherrypick went OK by building the branch and runnig (at least some) tests.
Then push the changes to the server:
After the push please make sure everything works by checking the state of MID-SUPPORT plan on Bamboo
We want to have mostly linear development because we want to integrate the code continually. All the time. We avoid branching. There are git-based models that use a lot of branching and merging (such as http://nvie.com/posts/a-successful-git-branching-model/). We don't like these models for midpoint core team. The core team is small and works well together. Although we use some topic branches we otherwise try to keep things simple and avoid branching.
Our focus is on the development of next midpoint version which happens on
master. All bugfixes usually go there. Backporting a fix mostly an exception. When we create a fix we do not know whether it will need to be backported later or not. Therefore we do the easiest thing which is also a common case: fix on
master. If the fix needs to be backported then just cherrypick it to support branch. Cherrypick creates new commit and efficiently breaks merging. But that's not a problem. We do not expect that we will ever merge support branch back to