How to get a bug fix into the release

After a release, we often have a ton of new bugs coming in. Many more people use the release compared to the release candidates, so this is to be expected. This is why we often issue "maintenance releases", that is a release from the same "release" branch with only bug fixes.

How to do a fix right

In order to easily integrate a bug fix into the next maintenance release, it is easier if the bug fix is developed from the scratch against the release branch. However, some bug fixes might be disruptive, and we would like to test them first against the master branch before putting them in the release branch.

We can develop the bug fix against master, test it, make some adjustments, then cherry-pick the changes into release. This is error-prone as master may contain some new developments that are absent in release.

The best way to proceed is to follow the procedure outlined below, depending on whether you are allowed to commit directly into the cgeo repository or not.

Procedure for direct committers who want to work directly into the main repository

• create a new branch (in our repository) forked off the release branch, called, e.g., issue-1722
• develop the fix in this branch
• when the fix is ready, merge it into master -- this should be an easy operation as release, from which the branch has been forked, is systematically merged into master, so master is a descendant of the branch point of issue-1722
• if the fix needs some adjustments, put them in the branch (issue-1722) and merge again against master, git will know what has been merged already and what needs further action
• repeat until the fix is satisfactory

At this stage, we have a branch fixing an issue which has been quite well tested and which is still based against the release branch. If we want to merge it into the release branch, we can do it easily, without ever cherry-picking a change (and thus letting git control the whole graph).

Procedure for contributors or for using pull requests and code reviews

People who cannot write to the repository, or people wanting to use GitHub pull requests, can do that by creating their branch off the release branch, and submit their pull request against master. This way, we can always later merge the tip of their branch (even if they have deleted it) into release because the fixes have been developed against the release branch in the first place.

Note: this procedure also let us decide what to put into the maintenance release once a fix has been tested. If we deem a fix too dangerous or not suitable for the maintenance release, we can just not merge it, and it will still be in master.

Attention: the merging needs to be done by a direct committer locally. When doing via GitHub the commit gets rebased and can't be easily merged into both master and release.