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