Question

I’m trying to find some solid information on the version numbers and branching/merging with Maven and SVN.

My projects use the Maven version rules:

<major>.<minor>.<revision>([ -<qualififer> ] | [ -<build> ])

My Maven release is as follows with snapshots in the trunk and release tags

trunk:    1.0.0-SNAPSHOT

tag:      1.0.0

trunk:    1.0.1-SNAPSHOT

tag:      1.0.1

etc....

Questions:

1. If I create a branch (from a release tag) in order to do a bugfix.
   When it comes to releasing this patch what number does the maven release plugin give it? What tag name does it get?
   Any recommendation on merging changes back into trunk?

2. What is the standard approach to changing the Maven version numbers? When do the Major, Minor and build numbers get incremented?

Any books or documentation that can shed some light on the recommended approach?

Answer 1

A quote from Better Builds with Maven – Mergere Library Press.

Section 3.6. Resolving Dependency Conflicts and Using Version Ranges:

If I create a branch (from a release tag) in order to do a bugfix. When it comes to releasing this patch what number does the maven release plugin give it? What tag name does it get? Any recommendation on merging changes back into trunk?

When doing mvn release:prepare, You will get chance to fill specific version name (release version, tag version, next trunk version and etc.) if you don’t like the one Maven generated. In some special case for instance build a patch release from branch, we usually set version name by ourselves:

• If changes doesn’t need to merge back to trunk (build release from branch), use 1.0.1-1 or 1.0.1-patch-1.

• If changes need to merger back to trunk (build release from trunk), for major change, use 2.0.0, for minor change, use 1.1.0, for bug fix, use 1.0.2.

What is the standard approach to changing the Maven version numbers? When do the Major, Minor and build numbers get incremented?

See the diagram above.

Update:

Yes this is another confusing part of maven versioning. For me the diagram contradicts whats written below it: It states the build number is incremented after releasing a patch. But I thought that was what the Bug fix part of the version string is for as shown in diagram??

The purpose of maven version ranges is to cover as many use cases as possible. How you intend to use it is completely up to you. The point here is which one is more reasonable. As I have stated in the original post, it is used in some special case, like your team need maintain two work stream simultaneously (main work stream on trunk and second work stream on branch).

Take this scenario as an example, after a long time of work, you build and deploy release 1.0.6 to your clients (in SVN, 1.0.6 is tagged and trunk is incremented to 1.0.7-SHAPSHOT, means next expected release version is 1.0.7), and continuously developing on trunk. Then two weeks later, a bug is reported in release 1.0.6 and requires urgent fix, so you create a branch from tag 1.0.6, fix the bug and merge branch back to trunk. Now you need build a patch release for client. As trunk has been changed quite a lot since last build (two weeks ago), we have to build this patch release from branch. Of cause, you can use anything you like (i.e. 1.0.7) for this patch release, which as a consequence need manually alter version in trunk (from 1.0.7-SHAPSHOT to 1.0.8-SNAPSHOT). However, I would prefer to use 1.0.6-patch-1 for this patch release.

Nothing is contradict in the diagram, the build number is perfect in this scenario, this is what it means "while the build number is an increment after release to indicate patched builds." It gives you a second chance to increment version targeting on an already-released version (1.0.6 -> 1.0.6-patch-1), not a ready-to-release development version (1.0.7-SNAPSHOT -> 1.0.7).