-
Notifications
You must be signed in to change notification settings - Fork 132
Releasing
See also Branching.
See Merging-Pull-Requests for details on how to merge in the contents of a pull request into the integration branch.
The release process is started when the integration branch almost, but not quite, is in a state when it makes sense to wrap up all the recent changes, new features, pull requests, bug fixes and so on and package them as a formal release.
A release branch originates from the integration branch and is named release-'major'.'minor'.
$ git checkout -b release-1.2 integration
Mapstraction's version number is controlled from the ant build file, build.xml. In this file, you'll find two properties, build.major and build.minor. It's up to the designated release manager and other committers to the project to decide whether a release should simply increment the minor release number or is deserved of a major release number hike.
The applicable section of build.xml which defines the version numbers for v2.1 of Mapstraction looks something like this ...
<property name="build.major" value="2"/>
<property name="build.minor" value="1"/>
The new version number can then be committed to the release branch created earlier.
$ git checkout -b release-1.2 integration
$ git commit -m "Upping version number to 1.2"
TBD
TBD
TBD
Once all the changes and additions that will be part of the release are finalised and locked down, the release is finalised.
Firstly the release branch is merged into master as every commit to master is in effect a new release.
$ git checkout master
$ git merge --no-ff release-2.1
Secondly the new release is tagged.
$ git tag 2.1.0
Thirdly the release branch is merged in integration so that master and integration are both in synch and in preparation for the next batch of work on integration.
$ git checkout integration
$ git merge --no-ff release-2.1
Finally, the release branch can be deleted, if desired.
$ git branch -d release-2.1