[EMAIL PROTECTED] wrote:
Knut Anders Hatlen <[EMAIL PROTECTED]> writes:
[EMAIL PROTECTED] writes:
I did some experimenting, and here are the results:
Alt A:
With maint=0000001 and beta=true
10.4.0.1 alpha - (635861)
Alt B:
With maint=0000001 and beta=false
10.4.0.1 alpha - (635861M)
Alt C:
With maint=1000001 and beta=true
10.4.1.1 beta - (635861M)
Alt D:
With maint=1000001 and beta=false
10.4.1.1 - (635861M)
So I thought alt. A was correct for the period from when the branch is
cut up to the point when the first RC is spun (targetted for
2008-04-04), alt. C for the RC and alt. D for the final release.
The release candidate should not have the beta flag. As long as it has
the beta flag it can't be released and therefore cannot be a candidate
for release... :)
But based on the comments I take it that I should go immediately to alt.
C, and that alt. D should be used for the RC. If someone confirms this
I can check in the change to release.properties and update the Wiki.
Sounds reasonable to me. Although I had expected the last digit to be 0,
not 1 (we did release 10.1.1.0 and 10.2.2.0, as far as I remember).
I don't know why it shouldn't be 0. But following the old instructions
on the Wiki (either by running maintversion2props directly, or by doing
ant bumplastdigit in tools/relase, which seems to be doing the same
thing) I ended up with the last digit being 1...
If it should in fact, be 0, then I have to ask that someone tells me
exaclty what to do, step by step, so that I can re-write the Wiki from
scratch...
Hi Dyre,
This part of our release process seems to trip up every new release
manager and the instructions could use some improvement. My
understanding of bumplastdigit is this: you run it after you generate a
candidate and it sets up the release id for the next candidate. In any
event, with or without bumping the last digit, option (C) produces a
release id that looks good to me.
Thanks,
-Rick
