commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: [all] Release artifacts and RCs (was Re: Validator 1.3.1 Release)
Date Wed, 29 Nov 2006 00:03:15 GMT
On 11/28/06, Rahul Akolkar <> wrote:
> On 11/28/06, Craig McClanahan <> 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).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message