For normal releases, just do the snapshot version bump after merging the release branch:
- Create the release branch off
developand remove the snapshot from the version - Merge it into
master - Merge it into
develop - Change the version on
developto the next snapshot version - Push both
masteranddevelop
As you push all the changes at the same time, the team will only see the snapshot version increase.
For hotfixes, this is not possible as you create it off the master branch. There is a workaround for this scenario, here’s an example using the raw git commands.
Example: You have 1.0.0 on master and want to create a 1.0.1 hotfix version. Your develop is already at 1.1.0-SNAPSHOT.
git checkout mastergit checkout -b hotfix/1.0.1- Make your hotfix!
mvn versions:set -DnewVersion=1.0.1git commit -a -m "hotfix release 1.0.1"git checkout mastergit merge hotfix/1.0.1(easy, because we created the branch offmaster)git checkout developmvn versions:set -DnewVersion=1.0.0git commit -a -m "workaround to avoid merge conflicts"git merge hotfix/1.0.1(will work because of the commit before)mvn versions:set -DnewVersion=1.1.0-SNAPSHOTgit commit -a -m "set version back to 1.1.0-snapshot"
Not very nice but it works. This solution is also used by jgitflow (a Maven plugin to support you with git flow).
A nice alternative is to not ever commit the version bumps in the pom.xml and to set it before your build is run on the CI server. Example CI Pipeline:
- Checkout the branch
- Derive release version from the branch name and enrich it with a build number or timestamp, e.g. for build 42 of
release/1.0.1it would be1.0.1-42 - Set the version using
mvn versions:set -DnewVersion=1.0.1-42 - Build the release and publish it
The version number will not be as pure, but you’ll never have merge conflicts anymore and you can always track a version back to it’s build.