db-derby-dev mailing list archives

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

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

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

Keep in mind that I have edited that page several times in the last
couple of days, so you need to look at an older version to see what it
originally said... The original version did not mention the 'ant
bumplastdigit' target. I added that beacuse I thought it superseded the
old 'ant regex.masters' target which no longer exists... 

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

This is the same as the C' alternative proposed by Rick isn't it? Seems
like Rick favors going directly to your step 2.

>   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, ...

Agreed.

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

Agreed. But I don't see what the purpose of the maintversion2props
program is (other than implementing ant bumplastdigit). 
Seems to me you could achieve exactly the same thing by just editing
release.properties by hand...

I would like to change the Wiki so that each step of the release process
becomes a cookbook, that the RM can follow. Specifically, I would like
to remove implicit dependencies on steps described elsewhere, even if
that should lead to some duplication.

-- 
dt

Mime
View raw message