With this approach, all RC tags (and the final one) point to a source code that generate the finalName artifact. more complete sample
from trunk 1.0-SNAPSHOT release:prepare version = 1.0 release:stage --> tag = 1.0 --> artifact = foo-1.0.jar, deployed on staging repository test, test, test BUG ! release:roolback --> trunk is back to 1.0-SNAPSHOT // rename the tag, as this one was a buggy RC svn mv tags\1.0 tags\1.0-RC1 go back to step 1 No bug found ? well done, you've got your release 2009/5/13 sebb <seb...@gmail.com> > On 13/05/2009, nicolas de loof <nicolas.del...@gmail.com> wrote: > > 1. release:stage with the target version 0.9 (renaming a released JAR may > > have some strange side-effects) > > > > test, test, test .. > > --> all fine ? you've got it > > --> some bugs : release:rollback , fix and back to step 1. > > You only have to rename (or remove) the tag created in SCM for the > release > > (candidate) > > I don't follow this - how does this ensure that a given tag name (URL) > only ever refers to a single code set? > > I may have misunderstood, but it seems to me that the tag is being > reused, and therefore does not uniquely identify the source. > > > > > 2009/5/13 Todd Thiessen <thies...@nortel.com> > > > > > > > So what is the extact work flow? > > > > > > 1. Run release:stage with a version like myproject-0.9-RC1 > > > 2. When problems are found, rollback, fix the problem and run > > > release:stage again, incrementing RC2, 3, etc.... > > > 3. When no more problems are found with the RC, perform a rollback and > > > then a release:perform using the actual release version. (in this case > > > myproject-0.9) > > > > > > --- > > > Todd Thiessen > > > > > > > > > > -----Original Message----- > > > > From: nicolas de loof [mailto:nicolas.del...@gmail.com] > > > > Sent: Wednesday, May 13, 2009 9:13 AM > > > > To: Maven Users List > > > > Subject: Re: How can one handle release candidates in Maven? > > > > > > > > Use the release:stage goal to create your release candidates. > > > > If you find a bug, you just have to release:rollback and > > > > rename the tag from finalName to finalName_RCx > > > > > > > > 2009/5/13 Fabien KRUBA <fabien.kr...@gmail.com> > > > > > > > > > I suppose you can use release:prepare and perform multiple times > if > > > > > you give the RC version number when asked ? > > > > > > > > > > http://maven.apache.org/guides/mini/guide-releasing.html > > > > > > > > > > > > > > > > > > > > On Wed, May 13, 2009 at 8:55 AM, sebb <seb...@gmail.com> wrote: > > > > > > > > > > > What I would like to be able to do with Maven is: > > > > > > > > > > > > Create an SVN tag, e.g. myproject-0.9-RC1 from current > > > > code in trunk > > > > > > (or perhaps a branch) > > > > > > > > > > > > Create and test the release candidate from the tag. > > > > > > > > > > > > Publish the release candidate somewhere temporarily so others > can > > > > > > check if the release candidate is OK. > > > > > > > > > > > > If there are problems, fix the trunk (or branch) and create a > new > > > > > > tag, e.g. myproject-0.9-RC2. Repeat as needed. > > > > > > > > > > > > Suppose RC3 is OK, then the artifacts need to be renamed (if > > > > > > necessary) to remove the -RC3 suffix, and published to > > > > the release > > > > > > repository. > > > > > > > > > > > > The tag is also renamed, i.e. myproject-0.9-RC3 => myproject-0.9 > > > > > > > > > > > > The end result is a published release (without RC suffix). > > > > > > > > > > > > The idea behind this is to ensure that the tag URL alone is > > > > > > sufficient to identify the exact contents used to create the > > > > > > release, and that the artifacts that are published are > > > > identical to > > > > > > the ones that were checked (apart perhaps from the file names). > > > > > > > > > > > > Is this possible using Maven? > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
