You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by sebb <se...@gmail.com> on 2009/05/13 14:55:49 UTC
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by sebb <se...@gmail.com>.
On 13/05/2009, nicolas de loof <ni...@gmail.com> 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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by sebb <se...@gmail.com>.
On 15/05/2009, sebb <se...@gmail.com> wrote:
> On 14/05/2009, Brian Fox <br...@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.
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-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
> > >>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by sebb <se...@gmail.com>.
On 14/05/2009, Brian Fox <br...@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 <an...@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 <se...@gmail.com> wrote:
> >>>
> >>>
> >>>> On 13/05/2009, Jason van Zyl <jv...@sonatype.com> wrote:
> >>>>
> >>>>
> >>>>> On 13-May-09, at 10:11 AM, sebb wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 13/05/2009, nicolas de loof <ni...@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 <se...@gmail.com>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> >>>>>
> >>>>>
> >>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>> users-help@maven.apache.org
> >>>
> >>>
> >>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>
> >>>>>
> >>>>>> To unsubscribe, e-mail:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> users-unsubscribe@maven.apache.org
> >>>>>
> >>>>>
> >>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>> To unsubscribe, e-mail:
> >>>>>>>>
> >>>>>>>>
> >>>>>>> users-unsubscribe@maven.apache.org
> >>>>>
> >>>>>
> >>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>
> >>>>>
> >>>>>> To unsubscribe, e-mail:
> >>>>>>
> >>>>>>
> >>>>> users-unsubscribe@maven.apache.org
> >>>>>
> >>>>>
> >>>>>> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by Sahoo <Sa...@Sun.COM>.
Brian,
Thank you for taking time to answer.
Sahoo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by Brian Fox <br...@infinity.nu>.
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,
> 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 <an...@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 <se...@gmail.com> wrote:
>>>
>>>
>>>> On 13/05/2009, Jason van Zyl <jv...@sonatype.com> wrote:
>>>>
>>>>
>>>>> On 13-May-09, at 10:11 AM, sebb wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 13/05/2009, nicolas de loof <ni...@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 <se...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
>>>>>
>>>>>
>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> users-help@maven.apache.org
>>>
>>>
>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>>
>>>>>> To unsubscribe, e-mail:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> users-unsubscribe@maven.apache.org
>>>>>
>>>>>
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>
>>>>>>>>
>>>>>>> users-unsubscribe@maven.apache.org
>>>>>
>>>>>
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>>
>>>>>> To unsubscribe, e-mail:
>>>>>>
>>>>>>
>>>>> users-unsubscribe@maven.apache.org
>>>>>
>>>>>
>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: How can one handle release candidates in Maven?
Posted by Sahoo <Sa...@Sun.COM>.
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? 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?
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 <an...@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 <se...@gmail.com> wrote:
>>
>>> On 13/05/2009, Jason van Zyl <jv...@sonatype.com> wrote:
>>>
>>>> On 13-May-09, at 10:11 AM, sebb wrote:
>>>>
>>>>
>>>>
>>>>> On 13/05/2009, nicolas de loof <ni...@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 <se...@gmail.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
>>>>
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>
>> users-help@maven.apache.org
>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>
>>>> users-unsubscribe@maven.apache.org
>>>>
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>>>
>>>>>>> To unsubscribe, e-mail:
>>>>>>>
>>>> users-unsubscribe@maven.apache.org
>>>>
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>> To unsubscribe, e-mail:
>>>>>
>>>> users-unsubscribe@maven.apache.org
>>>>
>>>>> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by Brian Fox <br...@infinity.nu>.
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 <an...@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 <se...@gmail.com> wrote:
> > On 13/05/2009, Jason van Zyl <jv...@sonatype.com> wrote:
> >>
> >> On 13-May-09, at 10:11 AM, sebb wrote:
> >>
> >>
> >> > On 13/05/2009, nicolas de loof <ni...@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 <se...@gmail.com>
> >> > >
> >> > >
> >> > >
> >> > > > On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> >> > > > > > > > > For additional commands, e-mail:
> users-help@maven.apache.org
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> ---------------------------------------------------------------------
> >> > > > > > To unsubscribe, e-mail:
> >> users-unsubscribe@maven.apache.org
> >> > > > > > For additional commands, e-mail: users-help@maven.apache.org
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > >
> >> > >
> >> > >
> >> > > > To unsubscribe, e-mail:
> >> users-unsubscribe@maven.apache.org
> >> > > > For additional commands, e-mail: users-help@maven.apache.org
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail:
> >> users-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: How can one handle release candidates in Maven?
Posted by Anders Hammar <an...@hammar.net>.
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 <se...@gmail.com> wrote:
> On 13/05/2009, Jason van Zyl <jv...@sonatype.com> wrote:
>>
>> Â On 13-May-09, at 10:11 AM, sebb wrote:
>>
>>
>> > On 13/05/2009, nicolas de loof <ni...@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 <se...@gmail.com>
>> > >
>> > >
>> > >
>> > > > On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
>> > > > > > > > > For additional commands, e-mail: users-help@maven.apache.org
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> ---------------------------------------------------------------------
>> > > > > > To unsubscribe, e-mail:
>> users-unsubscribe@maven.apache.org
>> > > > > > For additional commands, e-mail: users-help@maven.apache.org
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > >
>> > > >
>> ---------------------------------------------------------------------
>> > > >
>> > >
>> > >
>> > > > To unsubscribe, e-mail:
>> users-unsubscribe@maven.apache.org
>> > > > For additional commands, e-mail: users-help@maven.apache.org
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
>> Â For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by sebb <se...@gmail.com>.
On 13/05/2009, Jason van Zyl <jv...@sonatype.com> wrote:
>
> On 13-May-09, at 10:11 AM, sebb wrote:
>
>
> > On 13/05/2009, nicolas de loof <ni...@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 <se...@gmail.com>
> > >
> > >
> > >
> > > > On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> users-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > >
> ---------------------------------------------------------------------
> > > >
> > >
> > >
> > > > To unsubscribe, e-mail:
> users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by Jason van Zyl <jv...@sonatype.com>.
On 13-May-09, at 10:11 AM, sebb wrote:
> On 13/05/2009, nicolas de loof <ni...@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.
> 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 <se...@gmail.com>
>>
>>
>>> On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>>> ---------------------------------------------------------------------
>>
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by sebb <se...@gmail.com>.
On 13/05/2009, nicolas de loof <ni...@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.
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 <se...@gmail.com>
>
>
> > On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
> > ---------------------------------------------------------------------
>
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by sebb <se...@gmail.com>.
On 13/05/2009, nicolas de loof <ni...@gmail.com> 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 <th...@nortel.com>
>
> > 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.deloof@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 <se...@gmail.com>
> > >
> > > > On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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
> > > <se...@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-unsubscribe@maven.apache.org
> > > > > > > > > For additional commands, e-mail:
> > > > > users-help@maven.apache.org > > > > > > > > > > > > > > >
> > > > >
> > > --------------------------------------------------------------------
> > > > > - > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail:
> > > users-help@maven.apache.org >
> > > > > >
> > > > >
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by nicolas de loof <ni...@gmail.com>.
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 <th...@nortel.com>
> 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.deloof@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 <se...@gmail.com>
> >
> > > On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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
> > <se...@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-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail:
> > > > users-help@maven.apache.org > > > > > > > > > > > > > > >
> > > >
> > --------------------------------------------------------------------
> > > > - > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail:
> > users-help@maven.apache.org >
> > > > >
> > > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: How can one handle release candidates in Maven?
Posted by Todd Thiessen <th...@nortel.com>.
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.deloof@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 <se...@gmail.com>
>
> > On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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
> <se...@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-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail:
> > > users-help@maven.apache.org > > > > > > > > > > > > > > >
> > >
> --------------------------------------------------------------------
> > > - > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail:
> users-help@maven.apache.org >
> > > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by nicolas de loof <ni...@gmail.com>.
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 <se...@gmail.com>
> On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: How can one handle release candidates in Maven?
Posted by sebb <se...@gmail.com>.
On 13/05/2009, nicolas de loof <ni...@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by Jason van Zyl <jv...@sonatype.com>.
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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: How can one handle release candidates in Maven?
Posted by Todd Thiessen <th...@nortel.com>.
>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.deloof@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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by nicolas de loof <ni...@gmail.com>.
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 <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: How can one handle release candidates in Maven?
Posted by Todd Thiessen <th...@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.deloof@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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by nicolas de loof <ni...@gmail.com>.
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 <fa...@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 <se...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: How can one handle release candidates in Maven?
Posted by Fabien KRUBA <fa...@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 <se...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: How can one handle release candidates in Maven?
Posted by Jason van Zyl <jv...@sonatype.com>.
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:sebbaz@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: How can one handle release candidates in Maven?
Posted by Todd Thiessen <th...@nortel.com>.
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:sebbaz@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can one handle release candidates in Maven?
Posted by Jason van Zyl <jv...@sonatype.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org