On 13-May-09, at 10:11 AM, sebb wrote:
On 13/05/2009, nicolas de loof <[email protected]> wrote:
With this approach, all RC tags (and the final one) point to a
source code
that generate the finalName artifact.
more complete sample
Yes, but AFAICS the tag 1.0 points to different code at different
times, so does not uniquely identify the code.
Tags should not contain different code at different points in time.
That's just a bad practice. It happens by accident occasionally but to
change code on tags consciously is just a bad practice.
So if someone says that "the archives generated from tag 1.0" are OK -
or not OK - how do you know what code they are referring to?
from trunk 1.0-SNAPSHOT
release:prepare version = 1.0
release:stage
--> tag = 1.0
--> artifact = foo-1.0.jar, deployed on staging repository
test, test, test BUG !
release:roolback
--> trunk is back to 1.0-SNAPSHOT
// rename the tag, as this one was a buggy RC
svn mv tags\1.0 tags\1.0-RC1
go back to step 1
No bug found ?
well done, you've got your release
2009/5/13 sebb <[email protected]>
On 13/05/2009, nicolas de loof <[email protected]> wrote:
1. release:stage with the target version 0.9 (renaming a released
JAR may
have some strange side-effects)
test, test, test ..
--> all fine ? you've got it
--> some bugs : release:rollback , fix and back to step 1.
You only have to rename (or remove) the tag created in SCM for the
release
(candidate)
I don't follow this - how does this ensure that a given tag name
(URL)
only ever refers to a single code set?
I may have misunderstood, but it seems to me that the tag is being
reused, and therefore does not uniquely identify the source.
2009/5/13 Todd Thiessen <[email protected]>
So what is the extact work flow?
1. Run release:stage with a version like myproject-0.9-RC1
2. When problems are found, rollback, fix the problem and run
release:stage again, incrementing RC2, 3, etc....
3. When no more problems are found with the RC, perform a
rollback and
then a release:perform using the actual release version. (in
this case
myproject-0.9)
---
Todd Thiessen
-----Original Message-----
From: nicolas de loof [mailto:[email protected]]
Sent: Wednesday, May 13, 2009 9:13 AM
To: Maven Users List
Subject: Re: How can one handle release candidates in Maven?
Use the release:stage goal to create your release candidates.
If you find a bug, you just have to release:rollback and
rename the tag from finalName to finalName_RCx
2009/5/13 Fabien KRUBA <[email protected]>
I suppose you can use release:prepare and perform multiple times
if
you give the RC version number when asked ?
http://maven.apache.org/guides/mini/guide-releasing.html
On Wed, May 13, 2009 at 8:55 AM, sebb <[email protected]> wrote:
What I would like to be able to do with Maven is:
Create an SVN tag, e.g. myproject-0.9-RC1 from current
code in trunk
(or perhaps a branch)
Create and test the release candidate from the tag.
Publish the release candidate somewhere temporarily so others
can
check if the release candidate is OK.
If there are problems, fix the trunk (or branch) and create a
new
tag, e.g. myproject-0.9-RC2. Repeat as needed.
Suppose RC3 is OK, then the artifacts need to be renamed (if
necessary) to remove the -RC3 suffix, and published to
the release
repository.
The tag is also renamed, i.e. myproject-0.9-RC3 =>
myproject-0.9
The end result is a published release (without RC suffix).
The idea behind this is to ensure that the tag URL alone is
sufficient to identify the exact contents used to create the
release, and that the artifacts that are published are
identical to
the ones that were checked (apart perhaps from the file names).
Is this possible using Maven?
--------------------------------------------------------------------
- To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
