Gitflow is a branching model for Git where the develop branch contains staging modification and master branch contains released commits.
In this article, I will present you how we simplified maven version management to avoid merge conflict and ease our release process.
In this post I will talk about the default process (feature → develop → release → master) but the same thing can be done for hotfix process.
Here an example of a workflow :
The master branch contain 2 released version. Two feature start in the same time. When the first feature is finished a release branch is created but the second feature is merge before the end of the release.
With a classic maven version management we will have something like that :
There is three issues with this solution :
How do we know it will be a minor or a major version ? Maybe the next one prepared must be 2.0.0-SNAPSHOT ?
Where does I set 1.1.0 and 1.2.0-SNAPSHOT ?
For the last issue we tried to use the maven release plugin and the result was :
We can see that the version merged into develop is not the same as the version merged into master.
This create another issue where 1.1.0 is build twice, one time on release for validation and one time on master for tagged version.
The last issue with this process is that if a module is added on develop during the release process, merging the release branch will break the develop build because the new version is not on it.
Version from git
A common solution of the version management with gitflow is to deduct it from git tags. With this approch we do not care of version for every branches except master.
If we go back to the first example :
Version 1.0.0 and 1.1.0 will be github tags.
For all other commit we don’t care of the version, they can all be 0.0.0 or a more useful one like commitId.branch
Jgitver to the rescue !
Jgitver provide a way to calculate the semver version from git tags.
It can be integreted into maven by a maven-extension plugin.
For enabling the extension create
The plugin configuration will be done in
This configuration will create tags like
useSnapshot will force
-SNAPSHOT for non tagged commit.
This maven convention must be keep for publishing artifacts to a SNAPSHOT repository.
useDirty will add
-dirty to the version if it has been created with uncommited change.
This will avoid different version with the same commitId
New release process
Now we don’t need anymore update on pom version.
The releasing process is now to merge the release commit to master and add an annotated tag to it like
The fore issue with default maven version are solved - Choosing if the next version is a major, minor or even a bugfix is at the end of the release process when we know what is released. - Release version is only build on tagged commit on master branch - No more pom conflict for version update
You can use the exactly same workflow with a gradle project with gradle-jgitver-plugin
IntelliJ and subModule
Intellij IDEA use a custom version of maven that create issue with jgitVer.
In a future version of intelliJ it will be disabled by default,
but for the moment you must add
-Djgitver.skip=true in File > Settings > Build, Execution, Deployment > Build Tools > Maven > Importing > VM options for importing