commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <stei...@yahoo.com>
Subject Re: [lang] Going forward Was: [VOTE] Release of Commons Lang 2.0 [take 2]
Date Tue, 26 Aug 2003 19:26:47 GMT

--- Henri Yandell <bayard@generationjava.com> wrote:
> 
> First, let's make sure we keep the subjects on topic, and keep the [lang]
> there for anything other than a [VOTE].
> 
> Second, shall I tag the current changes to builder/ and lang/ changes.
> Unsure if it was all just javadoc chances. Guess I should dig through a
> changelog :) Assuming I do, should I go ahead and tag these to 2.0?

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


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Mime
View raw message