In maven projects the version of a project is contained in the <version>
attritbute of the pom.xml file. When creating a new release in the git flow model I need to bumb the version number. This article explains how this is done (without maven):
Additionally it says:
It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.
I see two problems in conjunction with maven here:
1.1-SNAPSHOT
. Now we have changed that to simply 1.1
on the release branch and merged that to master. Fine. But we should also merge that branch back to develop and for that we need to adapt the version to e.g. 1.2-SNAPSHOT
. And probably we should not have done that on the release branch because that commit should not be part of the release. Actually we probably should have made this change right after branching off develop because all future commits on develop will be for the next version.When googling for the problem I found some articles about maven-plugins that can automate the process, which may be interesting, but this question is really on how the git graph should look like and where the version bump commits should be and not how I can automate this using a maven-plugin.
For normal releases, just do the snapshot version bump after merging the release branch:
develop
and remove the snapshot from the versionmaster
develop
develop
to the next snapshot versionmaster
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
.
git checkout master
git checkout -b hotfix/1.0.1
mvn versions:set -DnewVersion=1.0.1
git commit -a -m "hotfix release 1.0.1"
git checkout master
git merge hotfix/1.0.1
(easy, because we created the branch off master
)git checkout develop
mvn versions:set -DnewVersion=1.0.0
git 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-SNAPSHOT
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:
release/1.0.1
it would be 1.0.1-42
mvn versions:set -DnewVersion=1.0.1-42
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With