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? 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:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
