Maven versioning in GitFlow

Question

Git Flow has been around for a long time and lots of people seem to be adopting it for as their favourite git workflow.

When it comes down to implementing Git Flow in a Java / Maven setting, I was wondering how one should approach versioning the software modules that live on all the branches below.

In a simplistic Maven world,

• developers always work on SNAPSHOT versions (ex: 0.0.1-SNAPSHOT)
• some release process create a release (0.0.1)
• A new snapshot version is made available for developers to develop on (0.0.2-SNAPSHOT).

If all you had was a Develop and Master branch this would be ok, but how do you handle maven versioning in GitFlow.

The versions on the master are pretty easy to define, as they will be the versions that are ultimately created and released from the Release branch.

But as soon as code goes to a release branch, what versioning strategy do you deploy here ?

• I guess we need to reserve a new version number on the release branch to avoid conflicts with Develop ? And how will that version number relate to whatever is on the develop branch.
• I assume that on the release branch there can also be multiple commits before the release goes into production. As we cannot re-use non-snapshot versions, do we increment fixed versions here with each commit, or also work with release-snapshot versions before finalising and pushing to master ?
• When we merge changes back from the release to the develop branch do we start a new snapshot version ?

Edema

The way Maven looks at release versioning predates git and its mindset quite a bit. With git the sha1-key of the commit is the version which is especially useful in a setting where you do not know which commit will be the one running in production when you commit. If you have the whole project in a single git repository then let maven work with snapshots only and use the git commit id as the version you use. – Sumner

"people seem to be adopting it for as their favourite git workflow" - this is not because it's good. But because people don't understand much about CI and modern dev processes like CD, JIT, ToC. GitFlow is a VERY outdated way of thinking about branching. There're much better alternatives, the best known way today is trunk-based development. Though it may be too advanced for some teams. In those teams you may want to start with simple FeatreBranch->master approach. – Unpracticed

@StanislavBashkyrtsev Yes, but what about teams that still release every 2 months or so and that still need a lot of manual testing before something can go to production? – M16

@JFMeier, rare releases don't make much of an impact on how you work with branches or versions. It may be easier to use FeatureBranches instead of FeatureToggles in the trunk (or maybe not - it varies), but that's about it. So GitFlow and complicated versioning don't have any benefits in case of rare releases either. – Unpracticed

@StanislavBashkyrtsev I just have the impression that bugfixing the productive version or fixing bugs on the beta while development has progressed is easier if you have release and hotfix branches. If the release needs weeks of manual testing (and bugfixing), it is hard to just have a master branch and nothing else. – M16

@JFMeier, you mean the case when you started to stabilize release branch, but new development has been started in parallel? You can hold this new development effort in FBs. So your master branch gets "locked" and no new features can be merged during this period. If this stabilization period is too long (which is a big problem) you may want to allow devs to push to some "develop" branch to integrate their changes together. But that would lead to even longer stabilization phase because they'll break a lot during this time. So if things can't fit FBs anymore it's often cheaper to halt dev work. – Unpracticed

Answer 1

For release branch we should following 0.0.1-RC-SNAPSHOT naming convention. Also please explore the mvn jgitlfow plugin. Which will provide all the above discussed features .

Please include the following depedency.

   <plugin>
                <groupId>external.atlassian.jgitflow</groupId>
                <artifactId>jgitflow-maven-plugin</artifactId>
                <version>${jgitflow-maven-plugin.version}</version>
                <configuration>
                    <enableSshAgent>true</enableSshAgent>
                    <noDeploy>true</noDeploy>
                    <noReleaseBuild>true</noReleaseBuild>
                    <noFeatureBuild>true</noFeatureBuild>
                    <noHotfixBuild>true</noHotfixBuild>
                    <enableFeatureVersions>true</enableFeatureVersions>
                    <releaseBranchVersionSuffix>RC</releaseBranchVersionSuffix>
                    <allowSnapshots>true</allowSnapshots>
                    <pushReleases>true</pushReleases>
                    <pushHotfixes>true</pushHotfixes>
                    <pushFeatures>true</pushFeatures>
                    <flowInitContext>
                        <versionTagPrefix>v</versionTagPrefix>
                    </flowInitContext>
                </configuration>
            </plugin>

Example cammands

mvn jgitflow:release-start

creates a release branch with RC and updates develop branch pom to next version

 mvn jgitflow:release-finish

Mergers relaese to master and develop and creates a tag : Mostly this branch goes Integration testing any bug fix are commited to the release branch, when it is closed develop also get the updates as it is merged.

creates a release branch with also updates the develop pom ie before (devlop 0.1-SNAPSHOT) After devlop 0.2-SNAPSHOT and a release branch of 0.1-RC-SNAPSHOT is create

https://bitbucket.org/atlassian/jgit-flow/wiki/Home

Stratify

Answer 2

I find that it is important to keep the areas of source control (managed by Git) and of building (managed by Maven) separate. In other words, managing versioning and branches should happen outside of your pom.xml files. It can still be achieve by means of some Maven plugin, but this plugin should not be a part of build process - it should be a tool external to this process.

Having this said, take a look at this description of Maven versions. You are right that when a release branch is created, a version X.Y.Z is "reserved" for this release (and develop branch atomically gets incremented snapshot version X.Y.(Z+1)-SNAPSHOT or X.(Y+1).Z-SNAPSHOT etc. depending on what kind of release is planned to be next). In meantime, your release branch will be existing for some time and you may need to change the version of your artefact between builds to avoid conflicts. This can be done by using build numbers or qualifier and a build number together. For example, you may start from X.Y.Z-alpha-0 and proceed till you change to X.Y.Z-beta-0 and onwards. You increment build number every time you need to deploy a "pre-release" artefact to your repository. Eventually, when release is made, your version X.Y.Z will be considered by Maven "greater" than all versions with build numbers and modifiers.

Euclid

Hey I'm currently learning Maven and I found something interesting in your answer. You mentioned-'managing versioning and branches should happen outside of your pom.xml files.' With my limited knowledge about Maven, if we want to use maven plugins, they are supposed to be added in the pom file, and how we can make it an external tool. I'm currently using 'gitflow-maven-plugin' for my project, I can only be able to update the final digit (Z) in version, not sure how I can test and update X and Y, also I'm thinking to combine it with Jenkins to make this process automatically, any thoughts? – Magneton

@Cecilia, You may still use Maven to run certain actions, just do so from a different pom.xml file (you may use option -f for that). The point is to adhere to the principle of separation of concerns: put test and build functionality for you project in main pom.xml and release and branching stuff in another file (it can also be outside of version control and be delivered by some Maven plugin invoked from command line). – Euclid

Answer 3

In our application , we had we were using the maven-release-plugin to update the version in the pom file. When we are using tools like Jenkins , whenever we configure a Job , we also have the provision to trigger downstream jobs. So in our case , we had the following setup :

1. A pull request from release to master was made and the build will run on release and of success it enables the merge.
2. When the merge occurs jenkins job was triggered to update the version in the pom to a snapshot one. After this a down-stream job was triggered to update the same snapshot version in the develop branch as well .

So , in our case whenever a release went through two version updates happened , that in one when the release version was cut and the other when the snapshot version is cut after release when merging to master and develop. So, in our master and develop after a release , the final version will always be a snapshot one. For some teams, I have seen that they only update the snapshot version in develop and push the release version directly to master (that is they merge to master from release without version change to snapshot and in down stream job change the version to snapshot when merging to develop).

For your question : I assume that on the release branch there can also be multiple commits before the release goes into production. As we cannot re-use non-snapshot versions, do we increment fixed versions here with each commit, or also work with release-snapshot versions before finalising and pushing to master ?

In an ideal case the release branch won't have direct commits to it. It will have to go through the develop to happen.So, yes the version needs to be incremented whenever you merge from develop to release as it is setup as a process.It's also easier to track bugfixes and features if you increment the version with each release.

Blink