commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [all] RCs and version numbers
Date Wed, 07 Feb 2007 20:51:51 GMT
Phil Steitz wrote:
> On 2/6/07, Henri Yandell <> wrote:
>> On 2/5/07, Oliver Heger <> wrote:
>> > Hi all,
>> >
>> > I am just in the progress of preparing the first RC for the Commons
>> > Configuration 1.4 release, but I am unsure about the version number to
>> > choose. As I understand it, before the vote is called the number has to
>> > be set to the final version of this release, i.e. 1.4 in my case.
>> >
>> > But before the vote, should the version number be 1.4-rc1? I think this
>> > would make sense, especially if this version is to hang around for a
>> > week or two giving users opportunity to test it and report issues they
>> find.
>> >
>> > Is this the correct way to proceed?
>> We have two ways:
>> 1) Do a mock release called 1.4-rc1. The version number of the source
>> is 1.4-rc1, it's tagged 1.4-rc1 etc. It can hang around for ages and
>> go into production if a user happens to find it and take it there.
>> What we are voting on is the release manager and not the release. I
>> believe I'm right in saying that this is becoming frowned on at the
>> ASF - but it might just be loud views from a minority - the central
>> release faq ( doesn't mention
>> it yet.
>> 2) Create the release and have it be voted on. The version number of
>> the source is 1.4, the svn tag is 1.4-rc1, the 1.4 files are put in a
>> 1.4-rc1 directory on your ~foo/ account. It's intended to let us vote
>> on the actual release and not to be used in production.
>> I don't know of Commons components (beside httpclient who have been a
>> separate community for a long time) who have intended rc1's etc to be
>> used by users. There's a definite problem with an rc1 being used by
>> users - if we tell users to use it then it becomes a release and if
>> we've not voted on releasing it then it can't be a release (see
>> release faq). It's better to just do the release and then release a
>> bugfix if people have problems. Some projects have a GA label they
>> apply after a release lasts a while without having a lot of bugs
>> applied to it, but I don't see the point of that, and especially don't
>> see the point of that for the size of our components.
> 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.
> Phil
Thanks for all the replies. I went for option 2) mentioned above because 
this seems to be the recommended way ATM (and probably more convenient, 

However I agree with Phil in most of his points. Having a jar labeled as 
the release version floating around, which is not the real release, 
seems to be dangerous.

Further I still think that an official announced RC is a good way of 
getting users to test the code. Many users hesitate to use nightly 
builds. But a RC suggests that a release is close now and that probably 
no dramatical changes will be made before that. So it is pretty save to 
play with such a version. So I assume that the user base that tests the 
new code grows significantly.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message