Return-Path: 
 <commons-dev-return-96284-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 83343 invoked from network); 29 Nov 2006 00:03:42 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 29 Nov 2006 00:03:42 -0000
Received: (qmail 65949 invoked by uid 500); 29 Nov 2006 00:03:50 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 65455 invoked by uid 500); 29 Nov 2006 00:03:49 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 65444 invoked by uid 99); 29 Nov 2006 00:03:49 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Nov 2006 16:03:49 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of flamefew@gmail.com designates
 66.249.82.234 as permitted sender)
Received: from [66.249.82.234] (HELO wx-out-0506.google.com) (66.249.82.234)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Nov 2006 16:03:37 -0800
Received: by wx-out-0506.google.com with SMTP id h27so2176555wxd
        for <commons-dev@jakarta.apache.org>;
 Tue, 28 Nov 2006 16:03:16 -0800 (PST)
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=S8NZwZGJvUr47HpfnwWUdBOdC4u82P0dh4YLxJiTXmnLunFByqfWhQtKH89igB1dFH+zVXGXbisvrWVid3C3nPTakOlx9GIq+H8YULQGr466t4oPsT7HTb61W5w7+P8ZeV47TqFnvkQ6erpw1Moq5CTNSxcqQYDdjQD+lErrcaI=
Received: by 10.90.94.2 with SMTP id r2mr1547363agb.1164758596250;
        Tue, 28 Nov 2006 16:03:16 -0800 (PST)
Received: by 10.90.98.15 with HTTP; Tue, 28 Nov 2006 16:03:15 -0800 (PST)
Message-ID: <31cc37360611281603h49a0f5a8qb86fee21cdc0ddb3@mail.gmail.com>
Date: Tue, 28 Nov 2006 16:03:15 -0800
From: "Henri Yandell" <flamefew@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [all] Release artifacts and RCs (was Re: Validator 1.3.1 Release)
In-Reply-To: <ce1f2ea80611281320w6430118du32f435b7299b81e1@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: <ce1f2ea80611281320w6430118du32f435b7299b81e1@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

On 11/28/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On 11/28/06, Craig McClanahan <craigmcc@apache.org> wrote:
> <snip/>
> >
> > 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.
> >
> <snap/>
>
> Yes, thats how its done. However, it needs to change, IMO.
>
> We could up the version numbers when it comes time to vote and point
> to the exact set of bits in the vote (but leave the tagging to until
> the vote passes -- assumes the "release workflow" to be 1 or more RCs
> followed by 1 or more votes).
>
> The m2 equivalent of staging.

Oops. I replied on the original thread.

+1 to changing.

We should:

1) SVN tag each RC.
2) Put it up on in ~foo/component-version-rc1/
3) Create files for the actual release - ie) don't put the rc1 in the
project.xml or any of the sites.
4) Vote. If it passes then:
4.1) Copy files to release locations.
4.2) Copy the successful RC tag to the official tag.
4.3) Deploy site.

There is a problem with this - dates. If the date is in the release
then there are problems as you have to reroll the release to get the
date right. If it's just in the site then it's not a problem (ie:
changes.xml report) as the site isn't tied to the release vote - it
can go again 5 minutes later with the date applied.

If the site is put in the release in lieu of documentation - no idea
(serves you right! - okay, so I don't like that style of documenting).

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org