When should mvn release be used in the project lifecycle?

Question

To clarify the question :

• I am looking for established best-practices or a pro/con analysis of known practices
• by project lifecycle I mean : deploy to pre-integration, integration, QA, preprod and prod environment.

For some context: Our project deploys to integration and QA every week, currenlty we create a new release for each integration deployment, but this doesn't feel right. It leads to updating all the poms every week breaking dev level dependencies, forcing every dev to do a refresh of their eclipse configurations. We have large workspaces and eclipse doesn't handle the refreshes so well thus a lot of wasted time.

I am not overly familiar with the maven release conventions and have been unable to find the ones regarding the point of the application lifecycle when mvn release should be used.

If the pattern we use now is accepted/correct/established I will have another question :)

Answer 1

The approach I use to avoid the Eclipse dev level dependency update issue is to leave the relevant trunk or branch version number unchanged until such time as the release becomes significant. This way you can have properly tagged/versioned releases to QA etc so that you can track issues back but not require devs to update dependencies. To achieve this I use the following command but override the version numbers to get the desired release number but re-enter the current snapshot version as the new snapshot version:

mvn release:prepare -DautoVersionSubmodules=true

P.S. I have a diagram that demonstrates this but unfortunately insufficient rights in this forum to attach it. I would happily provide it if someone can facilitate attaching.

P.P.S Maybe now...

Note also the support for early branching (2.1) and late branching (2.2).

Answer 2

In our shop, all of our POMs in SVN have <version>9999-SNAPSHOT</version> (for their own version as well as internal dependencies). This never changes.

During the build, we have a simple ant build.xml that takes the version number (established outside of maven) as a -Dversion=... parameter, and simply does:

<replace includes="**/pom.xml" token="9999-SNAPSHOT" value="${version}"/> <artifact:mvn ... />

That change is local to the build process's working copy -- it's never checked in to version control.

This way all release builds have a "real" version number, but dev effectively never has to deal with version numbers.

The above is, as you say in your question, emphatically not The Right Way to do this, but it has worked well for us for the ~9 mos since we adopted maven. We have tens of maven modules, all of which move in lock-step through the QA/release process.

One implication of this approach is that you'll need separate eclipse workspaces for each branch you're working on, as otherwise the copies of a project from dif't branches will collide.