commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: [all] RCs and version numbers
Date Thu, 08 Feb 2007 08:57:11 GMT
Phil Steitz wrote on Wednesday, February 07, 2007 9:05 PM:

[snip]

> Could be this is the direction that we need to go for the
> heavily reused
> components.  I cut an RC1 for [dbcp] a couple of weeks ago
> and published
> the RC1 snap to the snapshot repo so people could download
> and test.  I was
> afraid to do what I would have liked to - make it a "public"
> RC as we used
> to do, announcing it on tomcat-user, Jakarta general, etc,
> but I really
> think that is the right way to go. Testing RCs is an important part of
> getting to GA, IMHO and if it offends the gods to put RCs out
> for general
> consumption, then I think we need to move to the initial release, GA
> labelling.  I don't like the idea of having people download and test
> *different* jars with the same names / artifact ids and I don't like
> releasing components that have not been tested.
> 
> The problem with the release-then-fix approach is it leads to lots of
> dot-different release jars out in production use, some of
> them potentially
> bugged, and I don't see that as good in a mavenized world or
> for heavily
> reused libraries in general.  It works OK for "top predators"
> like Struts,
> Tomcat, HTTPd, but could get dicey lower down in the food
> chain, IMHO.  I
> could be cracked here - pls let me know if I am the only one
> thinking this
> way.
> 
> I'm strongly in favour of 2). It's safer and it makes the release
>> easier. The only negatives are:
>> 
>> 1) There's a chance that someone might take a jar from the rc1/
>> directory in ~bayard and charge off to use it. So be it - that's
>> there risk. 
>> 
>> 2) I don't like leaving svn in a state of having a release version,
>> so I roll the version back from 1.4 to 1.4-SNAPSHOT after doing the
>> release. An alternative might be to branch 1.4 off for the release
>> and have a 1.4-release branch for preparing the release on, but that
>> a) still makes me uncomfortable to have a release version in and b)
>> will be messy having one of those for every release.
> 
> 
> If we have to do things this way, I would use a release
> branch, but I still
> don't yet see the compelling need to reverse history - i.e.,
> what problem
> exactly are we needing to solve here?  What exactly is illegal about
> publishing release candidates and having people test them?  We publish
> nightlies now and the "RC" designation, which is clear and in
> all of the
> names, tells users that the artifacts are not yet official
> releases.  I am
> not trying to be difficult here, just want to understand what
> the issue is.

+1

It should not be a problem to make a final release after a RC has passed the vote. If you
don't trust your build tool to (re)create the same artifact now with the final revision number,
it seems it is more a question of trusting that build tool ... :D

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message