commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [VOTE] Release of Commons Lang 2.0 [take 2]
Date Tue, 26 Aug 2003 03:23:35 GMT
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 :-)

Sorry if I misunderstood things. I thought we were still adding things 
to the release. I see no reason to freeze code if we have a tagged 
release.  I am +1 for releasing the code prior to the javadoc changes 
that occurred during the vote or to adding them and retagging. If that 
requires a new vote, then I am OK with that as well.

In any case, we should not have to stop everything as we wait for the 
release to go. I would also very much like to see 2.0 get out the door.

Phil

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




Mime
View raw message