commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [VOTE] Validator 1.3.1 Release
Date Tue, 28 Nov 2006 23:58:20 GMT
On 11/28/06, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> On 11/28/06, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> > On 11/28/06, Craig McClanahan <craigmcc@apache.org> wrote:

> > > Follow up comment on something I missed (and will apply to Rahul's digester
> > > release candidate as well).  Are you planning on respinning the bits with
> > > the correct version number (1.3.1 instead of 1.3.1-RC1) before the actual
> > > vote?  I prefer to vote on the real bits for an actual release.
> >
> > I wasn't planning to as its not the procedure[1] Commons is currently
> > using. I agree that this is a weakness, since theres potential for
> > mistakes when the final release is cut. This needs commons to agree a
> > policy change though.
>
> Actually I changed my mind - its only a subversion tag which can be
> deleted and re-tagged. I'll do this and upload the proposed final
> artifacts to ~niallp @ apache.
>
> Niall
>
> > [1] http://jakarta.apache.org/commons/releases/prepare.html

This is a reason why it's bad:

http://svn.apache.org/repos/asf/jakarta/commons/proper/discovery/tags/DISCOVERY_0_3/

If you tag the RC's as real releases, then there's a large time period
in which a) people can be confused and b) you could lose time and the
release never happen. In the above case that didn't happen - the
release got passed the voting and just wasn't made, but it highlights
why the above would be more dangerous than the current system.

So, -1 to a tag of VALIDATOR_1_3_1 at this stage, and -1 to putting it
in ~niallp/validator-1.3.1/, it should be in
~niallp/validator-1.3.1-rc2/ (or whatever we're on). However +1 to the
file structure you have - we shouldn't be pissing around with 1.3-rc1
in the project.xml etc, we should be just trying for the real release
and then copying those exact files off to the various places.

Hen

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