db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Preparing to cut the 10.4 branch
Date Tue, 11 Mar 2008 12:58:00 GMT
Dyre.Tjeldvoll@Sun.COM writes:

> Knut Anders Hatlen <Knut.Hatlen@Sun.COM> writes:
>
>> Dyre.Tjeldvoll@Sun.COM 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...

I haven't followed the steps on the wiki myself, but by reading it, it
seems like this is what should happen with the version numbers:

  1. After creating the branch, "ant bumplastdigit" (step 5 under
     "Prepare the community for a new release") will change the version
     from 10.4.0.0 to 10.4.0.1. This sounds OK as it will help us
     distinguish between 10.4 on the trunk and 10.4 on the branch.

  2. Before creating the first release candidate, update both the third
     and the fourth digit of the version number by updating the maint
     property in tools/ant/properties/release.properties, and set the
     beta property in the same file to false. After this step, the
     version number shuld be 10.4.1.0.

  3. Before creating subsequent release candidates, update the fourth
     digit (either by manually updating release.properties or by running
     "ant bumplastdigit"). After this step, the version number should be
     10.4.1.1, 10.4.1.2, ...

The wiki page does not distinguish between (2) and (3), it only says
this under "Check-ins just before generating release artifacts":

> Bump the version number, adjust the beta flag and check in the new
> version.
>
>      The third and fourth parts of the version are combined into a
>      single property, maint, where maint = (third digit * 1000000) +
>      fourth digit. Also, if this is a major/minor (feature) release,
>      you should remove the beta flag at this time. You should update
>      tools/ant/properties/release.properties by hand and then run:

So according to this paragraph, you should edit release.property by
hand, and then you can set maint to whichever number you'd like before
you run maintversion2props.

-- 
Knut Anders

Mime
View raw message