Which version should I use in a Maven project during development if I want to release alphas, betas, and rc's as well?

Question

Background

For the last couple of months I have been getting my feet wet with Java projects with a Maven build. My team works on a (now Mavenized) project that has a regular release cycle, were we branch from our development branch (in git) when the project contains all the features we want in the release, and enter an internal testing phase. When the bugs have been ironed out, we deploy the project in an acceptance environment, where our customers get the chance to approve the product before we move to production.

Up until now we have used this simple versioning scheme:

• During development, testing, and acceptance, the project version number is (for example) 1.0.0-SNAPSHOT
• When 1.0.0-SNAPSHOT is branched off for testing, the development version on the master branch is set to that of the next planned release (1.1.0-SNAPSHOT)
• The final version is tagged and released as version 1.0.0

The branching model (stripped of all feature-branches etc.) looks like this:

                      (release-1.0)
                   ╭─── 1.0.0-SNAPSHOT ── 1.0.0 ──╮
── 1.0.0-SNAPSHOT ─┴─────── 1.1.0-SNAPSHOT ───────┴── 1.1.0-SNAPSHOT ──
  (master)

This is okay, but it is a bit sloppy to deploy Maven snapshots as release candidates during acceptance, and during the internal testing round it is nice to have released alphas and betas, so bugs can be filed (and thus reproduced) on an exact version.

Now the version numbers might look somewhat like this in the branching model:

                    (release-1.0)
                 ╭─── 1.0.0-rc1-SNAPSHOT ── 1.0.0-rc1 ── 1.0.0-rc2-SNAPSHOT ── 1.0.0-rc2 ── 1.0.0 ──╮
── ???-SNAPSHOT ─┴─────────────────────────── ???-SNAPSHOT ─────────────────────────────────────────┴── ???-SNAPSHOT ──
  (master)

Also, there may or may not be a number of alpha and beta releases preceding these release candidates.

Question

Now my problem is that xxx-SNAPSHOT, in Maven parlance, basically means the version that will become xxx. But if we start releasing release candidates and such, the upcoming release that the master branch becomes after branching off is no longer xxx-SNAPSHOT, because although it sorts before final release xxx, it comes after xxx-rc1 (and xxx-alpha1).

So what should my initial development version be in this model?

One possible solution I came up with is setting the version number on master to xxx-alpha1-SNAPSHOT after the release branch splits off, but I wonder if there is some sort of convention or best practice for this that I am overlooking.

Answer 1

In the end we chose to go with naming the first SNAPSHOT version of a project that has alphas, betas, and release candidates VERSION-alpha1-SNAPSHOT, where VERSION is the upcoming version.

So if we've branched from master to eventually release 1.0.0, the next commit on master sets the version to 1.1.0-alpha1-SNAPSHOT. This is a bit ugly, but a suitable solution in our case, and stays close to the version naming convention seen in most Java libraries.

For simpler projects we don't use alphas, betas, and release candidates, so there the problem does not exist.

hwellmann's answer is also a good approach, recommendable if you use a lot of packages that follow the JBoss way of naming versions.

Answer 2

This is what you see on most JBoss projects:

1.0.0.Alpha[n]
1.0.0.Beta[n]
1.0.0.CR[n]
1.0.0.Final