On 2/7/07, Phil Steitz <[EMAIL PROTECTED]> wrote:
On 2/6/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
>
> 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.
(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.
Yeah, the IO release in which a user has just reported that one of the
methods wasn't static is an example of something that would lead to
needing another release and wanting to have had that be something less
definitive as a release.
Perhaps its the terminology. What you're describing is an alpha/beta
to me. We have two levels of quality:
1) Design/code quality.
2) Release quality.
The first is alpha/beta/final, though putting final in the version
name always seems lame.
The second is whether the release was correctly built.
So I'd envisage calling a vote on:
dbcp-1.2.2-alpha-rc1/dbcp-1.2.2-alpha.jar
This is what Struts et al mean when they do their GA stuff (I think) -
except that they found that they got more people looking at something
if they do: 1.2.2 and then 1.2.2-GA, than if they do: 1.2.2-alpha and
then 1.2.2. Which I think is just gaming the users.
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 think it's a problem, but it's no different in the alternative
world. httpclient-rc3 was in many many production environments.
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?
If the reverse history bit means the rolling back - I don't like to
ever have release versions in a trunk or branch. Too easy for mistakes
to happen.
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.
As I understand it from Roy's view on a long thread on infra list:
["UH WHAT? www.apache.org/dist? YOU MUST BE JOKING, RIGHT?" thread -
for some reason infrastructure@ isn't archived so I can't link to it.
As you'll see in the thread, I was 'somewhat' -1 and I suspect I'm not
an efficient messenger for the message]
Nightly - Tests the build system. Intended for the development
community. Not advertised.
Releases - Actual release voted on by PMC. Advertised.
A not-voted on release is a contradiction in those terms. So we can
have an rc that is mentioned to the development community and not the
general public and people can look at it - but it definitely hasn't
been released. I think the -user@ list is part of the development
community, so I think this just means not putting it on the
distribution mechanisms (maven central repo, www.apache.org/dist) or
the website.
If we use RC to mean this, then I think we should use something else
for the 'getting the release itself right' as opposed to the code.
--
As a parallel to the "What is a release?" bit, there's the question of
what we should be voting on. The Struts way is to vote on the actual
binaries and not the release process. We've typically voted on the
release process [ie) 1.0 never had a vote, it was really 1.0-RC5 that
had the vote and successfully (we hope) became 1.0]. Given the length
of time between building the RC and doing the release, I know I'm
happier with using the thing I built a week before.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
