Release Branch Merging Policy
Intro
It is important to follow a particular pattern when keeping release branches and integration branches up to date.
Glossary
- integration branch - In Mifos land, this is the "master" branch in the head git repo at sf.net. All bleeding-edge development code is integrated and tested on this branch.
- release maintenance branch - Releases are sometimes augmented by minor updates (bugfixes, etc.) while excluding new features and non-critical bugfixes. These types of changes are recorded on a branch separate from other integration branches.
- release engineering branch - A release-specific branch for changes for change that must be in the release, but must not be in future releases (ie: hard-coding the release name in application/pom.xml).
Procedure
In preparation for a release, release branches are created.
Changes for the imminent release and future releases
Commit to the release maintenance branch, merge to master.
Changes only for the imminent release
Sometimes we have changes to commit to a release that cannot be in future releases. For example, the database used by the G-Release test server. Make these changes on the release engineering branch. This branch will never be merged to master.
Never merge from master to the release branches
This is likely to pull in changes for future releases that should not be part of the imminent release.
Whoops, I committed to master first!
If you accidentally commit something to master first that also should be in the release branches, just cherry pick it from master. Future merges from the release maintenance branch to master will do the right thing.
Whenever you "git cherry-pick" between two publicly visible branches (like master and g-maint), please use the "-x" argument so the original (source) commit is mentioned in the new commit.
See also
Specific examples of release branch merging policies:
Inspiration for separating release maintenance and release engineering: