On 14/05/2009, Brian Fox <bri...@infinity.nu> wrote: > On Thu, May 14, 2009 at 3:19 PM, Sahoo <sa...@sun.com> 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. 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-xxxx. 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 restage > >> one final time using the new release number (eg 2.0.9). The original RCs > >> were never called for formal votes as we know it's unlikely to pass, think > >> of them as tagged snapshots. Only the final release is voted upon and in > >> this fashion, by the time we reach the final release it's highly unlikely > >> we > >> will find any showstoppers, since 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 <and...@hammar.net> 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 <seb...@gmail.com> wrote: > >>> > >>> > >>>> On 13/05/2009, Jason van Zyl <jvan...@sonatype.com> wrote: > >>>> > >>>> > >>>>> On 13-May-09, at 10:11 AM, sebb wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> On 13/05/2009, nicolas de loof <nicolas.del...@gmail.com> 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 <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 > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> --------------------------------------------------------------------- > >>>>> > >>>>> > >>>>>> 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 > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> > >>>>> 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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
