On Thu, May 14, 2009 at 3:19 PM, Sahoo <[email protected]> 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, > 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> >>>> On 13/05/2009, Jason van Zyl <[email protected]> wrote: >>>> >>>> >>>>> On 13-May-09, at 10:11 AM, sebb wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> On 13/05/2009, nicolas de loof <[email protected]> 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 <[email protected]> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 13/05/2009, nicolas de loof <[email protected]> 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 <[email protected]> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> 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:[email protected]] >>>>> >>>>> >>>>>> 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 <[email protected]> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 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 <[email protected]> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> 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: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> [email protected] >>>>> >>>>> >>>>>> For additional commands, e-mail: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> [email protected] >>> >>> >>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>> --------------------------------------------------------------------- >>>>> >>>>> >>>>>> To unsubscribe, e-mail: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> [email protected] >>>>> >>>>> >>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>> >>>>> >>>>>> >>>>>>> >>>>>>>> To unsubscribe, e-mail: >>>>>>>> >>>>>>>> >>>>>>> [email protected] >>>>> >>>>> >>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> >>>>> >>>>>> To unsubscribe, e-mail: >>>>>> >>>>>> >>>>> [email protected] >>>>> >>>>> >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >> >> >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
