commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <>
Subject Re: [all] Release artifacts and RCs (was Re: Validator 1.3.1 Release)
Date Wed, 29 Nov 2006 09:28:11 GMT

I am release manager of ant.

I *presuppose* a positive vote when I do a build, and the public  
version number is preset in advance everywhere including in the SVN tag.

For instance on Sunday, December 10, I will build the release  
candidate which will hopefully become Ant 1.7.0.
Everything, including SVN tag, will be done in advance with this  
version number. The only thing is because of the habit of voting on  
actual bits, the
binaries will not go to /www/ until December 17 when  
the vote thread will be finished. Or if there is a failing vote they  
will go nowhere,
and the SVN tag will be moved when we think we can do a new build.

Even the documentation which is included in the release must contain  
the actual release date, so the doc included in the binaries on Dec  
10 will mention in advance a release date of Dec 17.
Otherwise the binaries would have to change between the vote on the  
release candidate and the actual release which I would not like.



On Nov 28, 2006, at 7:03 PM, Henri Yandell wrote:

> 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).
> Hen

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

View raw message