Hi,
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/www.apache.org 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.
Regards,
Antoine
On Nov 28, 2006, at 7:03 PM, Henri Yandell wrote:
On 11/28/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
On 11/28/06, Craig McClanahan <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
