commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] Doing the release
Date Mon, 25 Aug 2003 22:55:49 GMT
Well, we want a release that works, so if that means waiting then thats how
it goes. Don't want to miss the boat on any books or articles or other stuff
though.

I'm marshalling [collections] hoping for a release soon. Perhaps if [lang]
committers want something to do, the reflect code could be broken out into a
sandbox [reflect]? Or the [lang] sandbox could be used. Or there could be a
focus on [io].

I don't want to wait too long though, as [lang] feels like it might have the
energy to get a 2.1 in a couple of months to fill in any 2.0 gaps. Also, I
want to use [lang] at work!

Stephen

----- Original Message -----
From: "Henri Yandell" <bayard@generationjava.com>
> In addition to the question of us playing it a bit more by the rules, the
> Jakarta website is in a bit of a transition for a week or so. I'd rather
> not do any deploys until the move from daedelus to minotaur is complete,
> so am suggesting we back off until then. This sound doable?
>
> Hen
>
> On Sun, 24 Aug 2003, Gary Gregory wrote:
>
> > I'll take the blame for causing any confusion on this one since I had
> > committed these Javadoc changes "during" the vote, which was made more
> > difficult due to the extremely long email delays caused by the current
batch
> > of viruses going 'round.
> >
> > My thought was that we were indeed voting on the build based on tagged
> > sources and that any new commits would be in a post >2.0 release (even
> > though, these changes being Javadoc changes are "harmless" and
beneficial to
> > the release IMHO ;-)
> >
> > If we want to implement a code freeze in our environment on top of using
> > tags, we could do that. I guess we'd have to vote on it too :-)
> >
> > Gary
> >
> > > -----Original Message-----
> > > From: Noel J. Bergman [mailto:noel@devtech.com]
> > > Sent: Sunday, August 24, 2003 00:00
> > > To: Jakarta Commons Developers List
> > > Subject: RE: [VOTE] Release of Commons Lang 2.0 [take 2]
> > >
> > > > Well, if there is a question about policy/process, why not just
freeze
> > > the
> > > > code and restart the vote?
> > >
> > > By tagging the CVS, he effectively has frozen the code for the
Release.  I
> > > was simply curious about the policy because, as I said, other projects
are
> > > stricter.  For example the HTTPd team has different rules
> > > (http://httpd.apache.org/dev/release.html).
> > >
> > > A Release Manager makes a release build, and it is automatically an
alpha.
> > > It becomes a beta release when at least three Committers have voted
beta
> > > status, and there are more +1 than -1.  It becomes a GA release when
at
> > > least three Committers vote for GA (stable) status, and there are more
+1
> > > than -1.  Notice that -1 is not a veto.  Notice, also, that the
package
> > > itself may go through multiple status changes, but no packaging
changes.
> > > The only allowable change is renaming the file to reflect the change
in
> > > status; exceptions can be made if a change in the contents of the
tarball
> > > (e.g., someone forgot to add the LICENSE file).  Otherwise, if a
change in
> > > the CVS needs to be incorporated, it becomes a new release (with a new
> > > vote).
> > >
> > > Other projects, such as Avalon, also roll jars and then vote on them
as a
> > > Release.  So I was just asking to understand what is established as
policy
> > > here.  I wasn't challenging Henri's release.
> > >
> > > --- Noel
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> 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