commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [all] RCs and version numbers
Date Tue, 06 Feb 2007 20:47:04 GMT
On 2/5/07, Oliver Heger <oliver.heger@oliver-heger.de> 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 (http://www.apache.org/dev/release.html) 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.

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.

Hen

---------------------------------------------------------------------
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