How should I update the version inside my pom.xml when releasing using git flow? How should I update the version inside my pom.xml when releasing using git flow? git git

How should I update the version inside my pom.xml when releasing using git flow?


For normal releases, just do the snapshot version bump after merging the release branch:

  1. Create the release branch off develop and remove the snapshot from the version
  2. Merge it into master
  3. Merge it into develop
  4. Change the version on develop to the next snapshot version
  5. Push both master and develop

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.

  1. git checkout master
  2. git checkout -b hotfix/1.0.1
  3. Make your hotfix!
  4. mvn versions:set -DnewVersion=1.0.1
  5. git commit -a -m "hotfix release 1.0.1"
  6. git checkout master
  7. git merge hotfix/1.0.1 (easy, because we created the branch off master)
  8. git checkout develop
  9. mvn versions:set -DnewVersion=1.0.0
  10. git commit -a -m "workaround to avoid merge conflicts"
  11. git merge hotfix/1.0.1 (will work because of the commit before)
  12. mvn versions:set -DnewVersion=1.1.0-SNAPSHOT
  13. git 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:

  1. Checkout the branch
  2. 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.1 it would be 1.0.1-42
  3. Set the version using mvn versions:set -DnewVersion=1.0.1-42
  4. 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.


Keep in mind that Git was developed for the Linux kernel which has it's own version rules.

For Maven, you should create a release branch which gets the snapshot version of the next release. This change should be a single commit (i.e. just the change of the version number in pom.xml). When merging that, checkout master and use git merge --strategy=ours <release-branch>

--strategy=ours means: Make a merge by saying "everything in master has been correctly merged with the release branch"; no changes are being made to master. Afterwards, Git will treat the branches as merged (i.e. having no changes) despite the different version number in both branches.

To avoid all kinds of problems when building master with Maven, use an odd or very high version number which never changes like 99.DEV-SNAPSHOT.

When you make the release, strip the -SNAPSHOT from the version in the release branch and commit. Afterwards, you checkout master and merge once more with --strategy=ours.

Note: If you do this, you must not make any other changes on the release branch but changing the versions. Any other hotfixes will be lost! You can only cherry pick them.