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 :

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.

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 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

1
2
3
4
5
6
7
8
9

<extensions xmlns="http://maven.apache.org/EXTENSIONS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0 http://maven.apache.org/xsd/core-extensions-1.0.0.xsd">
    <extension>
        <groupId>fr.brouillard.oss</groupId>
        <artifactId>jgitver-maven-plugin</artifactId>
        <version>1.5.1</version>
    </extension>
</extensions>
	

The plugin configuration will be done in

This configuration will create tags like 0.0.0-shortCommitId-dirty-SNAPSHOT

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

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 1.0.0.

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 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

Demo project Jgitver