Phil Steitz wrote:
On 2/6/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
On 2/5/07, Oliver Heger <[EMAIL PROTECTED]> 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.
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,
too).
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.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
