SVN中的Maven发布周期和版本控制

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 (ie 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).

Answer 2

I would suggest to create a different numbering schemata in this case. So let us assume we create a branch from 1.0.0 Tag which might be named like 1.0.0-BFB. The version for the maven artifacts i would use a thing like this:

1.0.0.1-SNAPSHOT 

If you release this artifact the version number will go to:

1.0.0.1

This a solution for a single change which can simply be enhanced having multiple changes on the 1.0.0 line like this. Create the branch from 1.0.0 tag and name it like MB-1.0.0 and the version for the artifacts can be done like:

1.0.0.1-SNAPSHOT
1.0.0.1
1.0.0.2-SNAPSHOT
1.0.0.2
1.0.0.3-SNAPSHOT
etc.

By default the tag name in Maven is calculated by the name of the artifactId and the version.

The creation of such a maintenance branch can be done by the release plugin like this:

mvn -B -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false -DreleaseVersion=1.0.1-SNAPSHOT -DbranchName=MB-1.0.0 release:branch

The default solution to handle this situation is to use the parameters for the release plugin where you can use the developmentVersion or the releaseVersion as well. This will only work if you know that before you do the release.

But the usual case that you made a release and decided later to change the minor or major version. So you can use the release plugin as well like:

mvn org.apache.maven.plugins:maven-release-plugin:2.3.2:update-versions -DdevelopmentVersion=WhatEverVersionYouLike

Or you can use the versions-maven-plugin to update the version numbers.

Answer 3

You have complete control on what versions are given to your artifacts at release time.

Generally, with major.minor.patch versioning scheme the idea is that patch part is incremented for bug fixes, minor - for new features not breaking backward compatibility, major - backward incompatible changes and new major features.