Re: How can one handle release candidates in Maven?
On 15/05/2009, sebb wrote: > On 14/05/2009, Brian Fox wrote: > > On Thu, May 14, 2009 at 3:19 PM, Sahoo wrote: > > > > > Brian, > > > > > > Thanks for the excellent write up. In approach #2, when a build is done > by > > > just replacing RC versions by actual versions, since new binaries are > going > > > to be produced, don't they have to be tested again? > > > > > > > > Absolutely. However in the maven use case we don't need dozens of people > > testing every possible permutation like we try to do during the RCs. > > Assuming no code changed, we're really making sure that the binaries are > not > > completely broken. Regardless, this is the build that we do the voting on > so > > it does tend to have plenty of people using it before casting a vote. > > > > > > > > > I understand since no source code is changed(only version is changing in > > > pom.xmls), the chances of side effects are very low, but an organisation > > > with stricter quality control processes in place won't allow bits to be > > > released without them being tested. Once you involve testing, we are > back to > > > square one, where we are not sure if the bits are final. Or, am I > missing > > > anything? > > > > > > > > > Nope, you are correct and I agree with that policy. > > > > It's what we do at Sonatype as well as Maven. When a release is staged to > > Nexus, our QA thoroughly checks out that build. Those exact binaries are > > what eventually get promoted assuming they pass. > > > > I guess what I'm saying is that with the current maven release process, > you > > don't run RC's exactly the same way you do the final release. You need to > > rebuild it when you move from the RC to the release unfortunately, but you > > do still test the final binaries before promoting it. Sorry, one more question: What happens if an error is found in the final binaries? It's unlikely, but AFAICT it is not impossible. > > This is exactly what > > the Nexus staging is about, it lets you test the binaries before you > promote > > it to your release repo, where it's too late to pull it back. > > > > > Thanks for answering my question so thoroughly. > > > > > > > > > > Thanks, > > > Sahoo > > > > > > > > > Brian Fox wrote: > > > > > >> First, I'll acknowledge that it's not easy/possible to "promote" an > > >> artifact > > >> from one version to another - say 1.0-RC-10 to 1.0. Lets just accept > that > > >> for now as it's a known issue that will be resolved down the road. Lets > > >> instead discuss a few ways to work within those bounds, since > discussing > > >> what "could be" doesn't help the issue now (which i believe this thread > > >> derived from the discussion on commons-dev regarding a pending > release). > > >> There are two approaches to this process, both are valid and I think > you > > >> could pick one based on your requirements: > > >> > > >> The first is to append a build number to your version that is always > > >> incremented. So instead of 1.0 you have 1.0-1 or 1.0-b1. You increment > > >> this > > >> forever until you have a release that is good and that's the one that > > >> stays, > > >> it could be 1.0-b10 or 1.0-500. I've used this approach before and it's > > >> similar to what many commercial orgs do (if you look under the hood at > MS > > >> versions for example, Vista SP1 is 6001.16659.070916-1443). In other > > >> words, > > >> the marketing for a release might be "1.0" but the actual version of > the > > >> files might be 1.0-. This may be ok for things where the end > result is > > >> a > > >> war or ear but probably not as desirable for projects like commons that > > >> release jars that are intended to be consumed. > > >> > > >> > > >> The approach we use in the Maven project is slightly different. We > used to > > >> stage versions like 2.0.8 over and over until we got it right. The > > >> problems > > >> with this approach where: 1) you need to rollback the tag and versions > > >> every > > >> time and 2) someone may have an artifact called 2.0.8 that was actually > > >> not > > >> the final 2.0.8. This was a bigger problem when we wanted to start > getting > > >> maven-users involved to test the release candidates. > > >> > > >> We instead use the RC versions (eg 2.0.9-RC10) until we get to a > release > > >> that we decide is ready to do. The versions are all staged on Nexus and > > >> the > > >> binaries are ditched each time we rebuild, but the tags stay in place. > > >> Since > > >> each release is uniquely versioned, we no longer have to revert the > > >> versions > > >> and we don't have to worry about someone having an RC and thinking > it's a > > >> final release. Since it's not possible currently to promote an actual > RC > > >> to > > >> the final release (eg 2.0.9-RC10 to 2.0.9), we simply rebuild and >
Re: How can one handle release candidates in Maven?
> >>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On 13/05/2009, nicolas de loof 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 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> 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 >
Re: How can one handle release candidates in Maven?
Brian, Thank you for taking time to answer. Sahoo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can one handle release candidates in Maven?
ince the release process was followed for >> each >> RC (a practice run 10+ times if you will). >> >> Yes there are issues where someone _could_ make a change in between the >> last >> RC and the final release, but when we are in this cycle it is expected >> that >> only the RM is making changes to that branch (once the RC process starts, >> it's moved to a separate branch) and it's watched very closely. In reality >> it's not an issue. >> >> Hope that helps. >> Brian >> >> On Thu, May 14, 2009 at 5:35 AM, Anders Hammar wrote: >> >> >> >>> Hi, >>> >>> I don't mean to hijack this thread, but my experience is that test >>> people love traceability. Thus, I think they would expect a created >>> tag/label to stay as they file bug reports on it. (I guess this is out >>> of a larger non-agile organization's point of view.) >>> >>> Just my 2 cents, >>> /Anders >>> >>> On Wed, May 13, 2009 at 16:41, sebb wrote: >>> >>> >>>> On 13/05/2009, Jason van Zyl wrote: >>>> >>>> >>>>> On 13-May-09, at 10:11 AM, sebb wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> On 13/05/2009, nicolas de loof wrote: >>>>>> >>>>>> >>>>>> >>>>>>> With this approach, all RC tags (and the final one) point to a >>>>>>> >>>>>>> >>>>>> source >>> >>> >>>> code >>>>> >>>>> >>>>>> that generate the finalName artifact. >>>>>>> more complete sample >>>>>>> >>>>>>> >>>>>>> >>>>>> Yes, but AFAICS the tag 1.0 points to different code at different >>>>>> times, so does not uniquely identify the code. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Tags should not contain different code at different points in time. >>>>> >>>>> >>>> That's >>> >>> >>>> just a bad practice. It happens by accident occasionally but to change >>>>> >>>>> >>>> code >>> >>> >>>> on tags consciously is just a bad practice. >>>>> >>>>> >>>> I entirely agree. >>>> >>>> However AFAICT that is exactly what many Maven release procedures >>>> involve, because the tag is deleted and recreated. >>>> >>>> To go back to my original question - how does one use Maven with release >>>> >>>> >>> tags? >>> >>> >>>> The restriction is that a tag, once created, is never changed (it may >>>> be copied or deleted, but never updated or *re*created). >>>> >>>> >>>> >>>>> So if someone says that "the archives generated from tag 1.0" are OK - >>>>>> or not OK - how do you know what code they are referring to? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 13/05/2009, nicolas de loof wrote:
Re: How can one handle release candidates in Maven?
back to my original question - how does one use Maven with release
tags?
The restriction is that a tag, once created, is never changed (it may
be copied or deleted, but never updated or *re*created).
So if someone says that "the archives generated from tag 1.0" are OK -
or not OK - how do you know what code they are referring to?
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
On 13/05/2009, nicolas de loof 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
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
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
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
Re: How can one handle release candidates in Maven?
> > So if someone says that "the archives generated from tag 1.0" are OK - > >> > or not OK - how do you know what code they are referring to? > >> > > >> > > >> > > 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 > >> > > > >> > > > >> > > > >> > > > On 13/05/2009, nicolas de loof 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 > >> > > > > > >> > > > > > >> > > > > > >> > > > > > 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 > >> > > > > > > > >> > > > > > > > >> > > > > > > > I suppose you can use release:prepare and perform multiple > >> times > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > &
Re: How can one handle release candidates in Maven?
Hi, I don't mean to hijack this thread, but my experience is that test people love traceability. Thus, I think they would expect a created tag/label to stay as they file bug reports on it. (I guess this is out of a larger non-agile organization's point of view.) Just my 2 cents, /Anders On Wed, May 13, 2009 at 16:41, sebb wrote: > On 13/05/2009, Jason van Zyl wrote: >> >> On 13-May-09, at 10:11 AM, sebb wrote: >> >> >> > On 13/05/2009, nicolas de loof wrote: >> > >> > > With this approach, all RC tags (and the final one) point to a source >> code >> > > that generate the finalName artifact. >> > > more complete sample >> > > >> > >> > Yes, but AFAICS the tag 1.0 points to different code at different >> > times, so does not uniquely identify the code. >> > >> > >> >> Tags should not contain different code at different points in time. That's >> just a bad practice. It happens by accident occasionally but to change code >> on tags consciously is just a bad practice. > > I entirely agree. > > However AFAICT that is exactly what many Maven release procedures > involve, because the tag is deleted and recreated. > > To go back to my original question - how does one use Maven with release tags? > > The restriction is that a tag, once created, is never changed (it may > be copied or deleted, but never updated or *re*created). > >> >> > >> > So if someone says that "the archives generated from tag 1.0" are OK - >> > or not OK - how do you know what code they are referring to? >> > >> > >> > > 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 >> > > >> > > >> > > >> > > > On 13/05/2009, nicolas de loof 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 >> > > > > >> > > > > >> > > > > >> > > > > > 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:
Re: How can one handle release candidates in Maven?
On 13/05/2009, Jason van Zyl wrote: > > On 13-May-09, at 10:11 AM, sebb wrote: > > > > On 13/05/2009, nicolas de loof wrote: > > > > > With this approach, all RC tags (and the final one) point to a source > code > > > that generate the finalName artifact. > > > more complete sample > > > > > > > Yes, but AFAICS the tag 1.0 points to different code at different > > times, so does not uniquely identify the code. > > > > > > Tags should not contain different code at different points in time. That's > just a bad practice. It happens by accident occasionally but to change code > on tags consciously is just a bad practice. I entirely agree. However AFAICT that is exactly what many Maven release procedures involve, because the tag is deleted and recreated. To go back to my original question - how does one use Maven with release tags? The restriction is that a tag, once created, is never changed (it may be copied or deleted, but never updated or *re*created). > > > > > So if someone says that "the archives generated from tag 1.0" are OK - > > or not OK - how do you know what code they are referring to? > > > > > > > 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 > > > > > > > > > > > > > On 13/05/2009, nicolas de loof 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 > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > &
Re: How can one handle release candidates in Maven?
On 13-May-09, at 10:11 AM, sebb wrote: On 13/05/2009, nicolas de loof wrote: With this approach, all RC tags (and the final one) point to a source code that generate the finalName artifact. more complete sample Yes, but AFAICS the tag 1.0 points to different code at different times, so does not uniquely identify the code. Tags should not contain different code at different points in time. That's just a bad practice. It happens by accident occasionally but to change code on tags consciously is just a bad practice. So if someone says that "the archives generated from tag 1.0" are OK - or not OK - how do you know what code they are referring to? 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 On 13/05/2009, nicolas de loof 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 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 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 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha ---
Re: How can one handle release candidates in Maven?
I would not recommend the release:stage or the release:perform with an alternate repository. Maven used to do the latter which also required the use of the stage plugin which is terrible (I know because I wrote it). If you are going to take something and potentially expose it to a large group of people it needs to be managed by some intermediary where visibility is a logical change in configuration versus a physical movement of the files because too many thing can and do go wrong. One miffed POM screws up entire teams. People need configurable visibility, you have to make sure the files reached the server intact and you simply cannot change anything about the artifacts once they have been validated. All of this is supported in Nexus. In addition we can start adding to the workflow - validation of signatures - validation of the transitive closure, even taking into consideration upstream repositories - nice templates for mailing folks when releases are ready - automatic publishing policies (if after 72 hours with enough +1s, let it rip) All sorts of very cool and useful things are possible while increasing the integrity of the release fold an order of magnitude. On 13-May-09, at 9:41 AM, nicolas de loof 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) 2009/5/13 Todd Thiessen 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 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 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can one handle release candidates in Maven?
On 13/05/2009, nicolas de loof wrote: > Yes, the 1.0-RC1 tag generate a 1.0 artifact, don't you expect your RC to be > the EXACT artifact candidate ? I said to rename *if necessary*; I don't know how Maven derives the artifact name so I don't know if it can drop the -RC from the tag name. > Doesn't smell right to me to test some "1.0-RCx" jar and the rename it by > hand to "1.0". What to do if there is any side-effect ? Do I need to run all > my tests for second time ? I was referring to the archives, not individual jars. > > 2009/5/13 Todd Thiessen > > > Hmm. Doesn't renaming the tag mess up the tag? For instance the folder > > name would be 1.0-RC1 but the POM for the project would say 1.0. > > Something doesn't smell right with that ;-). > > > > --- > > Todd Thiessen > > > > > > > -Original Message- > > > From: nicolas de loof [mailto:nicolas.del...@gmail.com] > > > Sent: Wednesday, May 13, 2009 9:58 AM > > > To: Maven Users List > > > Subject: Re: How can one handle release candidates in Maven? > > > > > > 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 > > > > > > > On 13/05/2009, nicolas de loof 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 > > > > > > > > > > > > > > > > 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 > > > > > I > > > suppose you can > > > > > use release:prepare and perform multiple times > > > &g
Re: How can one handle release candidates in Maven?
On 13/05/2009, nicolas de loof wrote: > With this approach, all RC tags (and the final one) point to a source code > that generate the finalName artifact. > more complete sample Yes, but AFAICS the tag 1.0 points to different code at different times, so does not uniquely identify the code. So if someone says that "the archives generated from tag 1.0" are OK - or not OK - how do you know what code they are referring to? > 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 > > > > On 13/05/2009, nicolas de loof 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 > > > > > > > > > > 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 > > > > > > > > > > > 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 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 > > > > > > > re
Re: How can one handle release candidates in Maven?
Yes, the 1.0-RC1 tag generate a 1.0 artifact, don't you expect your RC to be the EXACT artifact candidate ? Doesn't smell right to me to test some "1.0-RCx" jar and the rename it by hand to "1.0". What to do if there is any side-effect ? Do I need to run all my tests for second time ? 2009/5/13 Todd Thiessen > Hmm. Doesn't renaming the tag mess up the tag? For instance the folder > name would be 1.0-RC1 but the POM for the project would say 1.0. > Something doesn't smell right with that ;-). > > --- > Todd Thiessen > > > > -Original Message- > > From: nicolas de loof [mailto:nicolas.del...@gmail.com] > > Sent: Wednesday, May 13, 2009 9:58 AM > > To: Maven Users List > > Subject: Re: How can one handle release candidates in Maven? > > > > 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 > > > > > On 13/05/2009, nicolas de loof 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 > > > > > > > > > > > > > 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 > > > > > 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 > > 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) > > > > > > > > > >
Re: How can one handle release candidates in Maven?
On 13-May-09, at 8:55 AM, sebb 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) Sure standard release:prepare from a trunk or more likely a branch. For Maven itself we always use a branch, but for plugins because they are released more frequently the trunk suffices. 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. For Maven we're using Nexus so you would do a standard release:perform and our configurations are setup to publish to a Nexus staging repository. The artifacts are visible to any group you like. The typical scenario is that a build is published for validation by QA but the artifacts are not visible to the general developer population. If there are problems, fix the trunk (or branch) and create a new tag, e.g. myproject-0.9-RC2. Repeat as needed. If you find the build is not good then you drop the staged repository and nuke the tag (this will be automated at some point but the release:rollback doesn't work). 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). You don't ever change anything about the validated artifact. To adhere to release management best practices signatures, names and coordinates cannot change for anyone who might have used the artifacts. The way QA people have tested it should be exactly the same as everyone else will use it. Changing the coordinate can introduce too much variation and potential problems. The idea behind this flow is that it's very convenient to test what might be published and drop/promote repositories as they are validated. While the artifacts are being validated they don't pollute any production repositories. When validation is complete the repository is promoted Nexus internally manages the configuration so that the artifacts become visible to the general population. And at Apache this additionally means promoting to Maven central. 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). Nothing can change about the release. It completely invalidates all testing. We could tighten up the management of the SVN URL management as nothing in SVN provides a guarantee of the contents of a tag at one point in time versus another. But in practice this not really a big problem. If you drop a repository that failed validation you have to go nuke the tag. Not really a big deal and we can fully automate this eventually. Is this possible using Maven? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How can one handle release candidates in Maven?
Hmm. Doesn't renaming the tag mess up the tag? For instance the folder name would be 1.0-RC1 but the POM for the project would say 1.0. Something doesn't smell right with that ;-). --- Todd Thiessen > -Original Message- > From: nicolas de loof [mailto:nicolas.del...@gmail.com] > Sent: Wednesday, May 13, 2009 9:58 AM > To: Maven Users List > Subject: Re: How can one handle release candidates in Maven? > > 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 > > > On 13/05/2009, nicolas de loof 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 > > > > > > > > > > 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 > > > > > 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 > 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 &
Re: How can one handle release candidates in Maven?
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 > On 13/05/2009, nicolas de loof 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 > > > > > > > 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 > > > > > > > > > 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 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 > >
Re: How can one handle release candidates in Maven?
On 13-May-09, at 9:09 AM, Todd Thiessen wrote: I am curious about this too. I do know of the staging repository option of the release plugin [1] but I have not actually used it yet. I don't "think" it does everything you are looking for. The pro version of Nexus has a staging suite [2] and this probably has what you are looking for but isn't free ;-). It's free for Apache projects, or any other OSS projects. [1] http://maven.apache.org/plugins/maven-release-plugin/usage.html [2] http://www.sonatype.com/books/nexus-book/reference/staging.html --- Todd Thiessen -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Wednesday, May 13, 2009 8:56 AM To: Maven Users List Subject: How can one handle release candidates in Maven? 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can one handle release candidates in Maven?
On 13/05/2009, nicolas de loof 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 > > > > 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 > > > > > > > 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 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
RE: How can one handle release candidates in Maven?
>From my understanding your steps would work if your staging repository is the same as your release repository. But how about if they are different? Are your proposing some kind of copying to the release repo once you have determined a RC is fine? --- Todd Thiessen > -Original Message- > From: nicolas de loof [mailto:nicolas.del...@gmail.com] > Sent: Wednesday, May 13, 2009 9:42 AM > To: Maven Users List > Subject: Re: How can one handle release candidates in Maven? > > 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) > > > 2009/5/13 Todd Thiessen > > > 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 > > > > > > > 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 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
Re: How can one handle release candidates in Maven?
On 13/05/2009, nicolas de loof wrote: > 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 So are you saying: create tag myproject-0.9 ... rename tag to myproject-0.9-RCn Then what? Re-create tag myproject-0.9? That would mean the tag "myproject-0.9" was not unique. > 2009/5/13 Fabien KRUBA > > > > 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 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
Re: How can one handle release candidates in Maven?
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) 2009/5/13 Todd Thiessen > 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 > > > > > 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 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 > >
RE: How can one handle release candidates in Maven?
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 > > > 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 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
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 > 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 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 > > > > >
RE: How can one handle release candidates in Maven?
I am curious about this too. I do know of the staging repository option of the release plugin [1] but I have not actually used it yet. I don't "think" it does everything you are looking for. The pro version of Nexus has a staging suite [2] and this probably has what you are looking for but isn't free ;-). [1] http://maven.apache.org/plugins/maven-release-plugin/usage.html [2] http://www.sonatype.com/books/nexus-book/reference/staging.html --- Todd Thiessen > -Original Message- > From: sebb [mailto:seb...@gmail.com] > Sent: Wednesday, May 13, 2009 8:56 AM > To: Maven Users List > Subject: How can one handle release candidates in Maven? > > 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
Re: How can one handle release candidates in Maven?
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 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 > >
How can one handle release candidates in Maven?
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
