That's effectively what happens during the [internal] QA process. We release 1.2.3-RC-1, ..., up to n, as needed. When its been qualified by the QA folks, the artifact is re-released *without* the '-RC-x' suffix.
After some basic smoke tests, a request is made to deploy the artifact into UAT where customers have access. Te UAT version lacks the '-RC-x'. Often the issues that arise in UAT are very minor, and it's been a pain to have to re-release to UAT [with a new version number]. These UAT-only releases never make it into production. I had hoped that the build number would replace our '-RC-x' versioning convention and allow QA to differentiate submitted artifacts having the same base version AND serve the same purpose within UAT. When we get to the 'final' UAT-approved version, it is what it is. No re-release would be required and the artifact can be deployed directly to production. Since we deploy via the 'release' plugin, the tag associated with that build is already on hand. Brad > -----Original Message----- > From: Nick Stolwijk [mailto:[EMAIL PROTECTED] > Sent: Friday, November 14, 2008 4:00 AM > To: Maven Users List > Subject: Re: buildnumber value not making it to local repo > > You could start a release branch with the release plugin and > start releasing release candidates, like 1.2.3-RC1, > 1.2.3-RC2, etc, until you have a final release and release > that as 1.2.3. > > Hth, > > Nick Stolwijk > ~Java Developer~ > > Iprofs BV. > Claus Sluterweg 125 > 2012 WS Haarlem > www.iprofs.nl > > > > On Fri, Nov 14, 2008 at 1:44 AM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > On Thu, Nov 13, 2008 at 5:33 PM, Harper, Brad > <[EMAIL PROTECTED]> wrote: > > > >> I was hoping that build number would let us iteratively refine an > >> artifact in UAT without relying on version number alone. > > > > Do you require the full release process with a tag for every one of > > these versions, or would unique snapshots (with the revision number > > baked inside) work for you? > > > > Here's an example of the version numbers: > > > http://people.apache.org/repo/m2-snapshot-repository/org/apache/tiles/ > > tiles-core/2.0.7-SNAPSHOT/ > > > >> It sounds like the best that can be done is to inject the build > >> number into jar/war manifest files. > > > > This is a good idea regardless. :) > > > > -- > > Wendy > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
