Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of flamefew@gmail.com designates
 66.249.82.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=RMK9/pDImX1bRSPXCEdBK6Jsq606XTDT86zkRzj1EAh5yjJPjPXZlnzUccu/670zCAvjcTrNy4FMzfeE/db8JKqvigYeJdY4oxIk8fsB8TjAkdB14Kwo6ExUeFmN8VDtwdbuAbCFBsqyAyKjAvdDXODP8pzjyFjEu5pM1JPmutU=
Message-ID: <31cc37360611281558n11369806t98866e52c6003301@mail.gmail.com>
Date: Tue, 28 Nov 2006 15:58:20 -0800
From: "Henri Yandell" <flamefew@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [VOTE] Validator 1.3.1 Release
In-Reply-To: <55afdc850611281423p5b8e366ci7dbf166913a11c66@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <55afdc850611280948j38fb962s18ec1c35908c872c@mail.gmail.com>
	 <f8b39ace0611281126g3a7e569rd3e5823a7417e897@mail.gmail.com>
	 <f8b39ace0611281309t5500ac74uc6ac05a72d0492cf@mail.gmail.com>
	 <55afdc850611281338k1d594253p832f8271169f0dde@mail.gmail.com>
	 <55afdc850611281423p5b8e366ci7dbf166913a11c66@mail.gmail.com>

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