DevOps Zone is brought to you in partnership with:


Maven the Version Number Nazi

  • submit to reddit



This was the problem:



Our verisoning is like this:









This effectively produces something looking like:









Mladen Girazovski replied on Mon, 2012/05/07 - 7:00am


 Let me put it this way: Stop abusing Maven version numbers ;)

Our verisoning is like this...

Sounds to me like your build/deploy/release process is not really aligned to Maven yet.

Maven has its own versioning scheme, instead of trying to change Mavens way, change your own way :)

Have you had a look at this plugin?

It should do what you want, except for naming the file the way you want, since it would break maven versioning scheme, instead you'll have the build number in your MetaData like MANIFEST etc. pp.


Jörg Buchberger replied on Mon, 2012/05/07 - 8:41am


if you need to change your version format ...

you might just as well also slightly change your group-ID.

Such a workaround would avoid the conflicts you outlined above. 




Bruce Baron replied on Mon, 2012/05/07 - 12:15pm

Version number Nazi? That's a bit harsh, considering there has to be some sane way to order version strings to determine if a particular version string is inside or outside a range.

Pieter Van Der Meer replied on Mon, 2012/05/07 - 2:13pm


 what wonders me is the following from your post: 


 How can this happen. What you are saying is that you have a non-reproduciable build. If so, why even bother with build numbers. The number has become meaning less. A defect found in build 4321 can not be reproduced, some environment change (which i dont know) introduced this defect...

 Just use the standard maven snapshot numbering and you are at the same point.

(btw I endorse the solution with the build number plugin. In general I create a custom manifest including my SCM revision number, timestamp and info about who or what created the artifact).


Loren Kratzke replied on Wed, 2012/05/09 - 11:52am

Basically, stop putting metadata (patch numbers and buildIds) in your version numbers. Use the manifest to hold that information and use some other system to report on it.

Furthermore, you pretty much need to do a Maven release with every build based upon your previous posts mentioning that you want every build to be a potential release. Just bite the bullet and release with every build. It is what you want to do anyway. Just do it.

The notion of every build being a potential release is unconventional at best. The Maven montra is convention over configuration.

Curtis Yanko replied on Tue, 2012/05/08 - 7:22am

Clasic case of solving a problem that doesn't exist. I ran into this when we were doing modular builds, the EAR projects tend not to increment so we started passing in the build number from the CI instead. However, if the intent is to reflect the repository version, you should check out from a level that is reflective of the whole project and not just the one module.

Pietro Martinelli replied on Thu, 2012/05/10 - 7:28am

What about using a numbering schema like

{major}.{minor}.{patch}-{timestamp} ?

 This schema complies with Maven standard schema but can differentiate different build of the same VCS snapshot, if you can pay the price of losing the reference to Perforce check-in number...

Comment viewing options
