maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Can't specify distributionManagement in settings.xml
Date Thu, 07 Oct 2010 17:34:18 GMT
This conversation turns on a classic dilemma in release management.

1. The important thing is to ship exactly the bits that have been
tested. Prepare a package, give it to QA. If they like it, ship it. If
they don't, rinse, lather, and repeat.

2. The important thing is to never, ever, ever create an artifact
named 'release x.y' until *after* QA has approved it.

Followers of the second religion like to rename things. They like to
build things that are labelled 'release candidate N', and then use
some surgical instrument or another to rename at the very end.

'Build numbers' as used by Microsoft (and supported in Maven) are a
sop to the #2 committee. If every build has a unique number, you can
start labelling something 'release 5' at an early phase in the release
process, and detect escaped early components via build numbers.

Maven is not very friendly to the followers of tendency #2. Maven aids
and abets you in injecting the version number all over the place. If
you want the package to be called 'release 5', you have to run the
build as 'release 5'. If you want it to be called 'release 5 candidate
1', you call it that -- and you're stuck with it.

Snapshots are a red herring, in my opinion. Since they don't
correspond to a tag, they don't make anyone happy.

In environments that follow the tendency of #2, I would suggest asking
yourself why you are using a maven repository *at all* when pushing
releases to QA and then out the door. If you are using the assembly
plugin, why not turn off 'attaching' altogether. That means that
nothing goes onto the repo until someone puts it there (with, say, the
deploy plugin by hand). So, you can set the version to a release
version, run a build, keep the results in a secret place where only QA
can get to them, and only burn white straw and push them out when QA
approves them.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message