Hello.
Sorry .... Not fourth, third .
> I think fourth version number should be increased when program was officialy released
,
> because rc-X is not yet program of the version officialy acknowledged .
I think third version number should be increased when program was officialy released ,
because rc-X is not yet program of the version officialy acknowledged .
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <tomonaka@basil.ocn.ne.jp>
To: "Derby Development" <derby-dev@db.apache.org>
Sent: Saturday, September 24, 2005 11:25 PM
Subject: Re: 10.1.2 Release status page
> Hello.
>
> I feel it strange that version number was decreased between rc-X and released version
......
>
> I think fourth version number should be increased when program was officialy released
,
> because rc-X is not yet program of the version officialy acknowledged .
>
> // Or preparing special version number ,such as 10.1.2.r0 10.1.2.r1 ... , for rc version
may be better ....
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomonaka@basil.ocn.ne.jp
> tomohito@rose.zero.ad.jp
> tmnk@apache.org
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "Daniel John Debrunner" <djd@debrunners.com>
> To: "Derby Development" <derby-dev@db.apache.org>
> Sent: Wednesday, September 21, 2005 10:28 PM
> Subject: Re: 10.1.2 Release status page
>
>
>> Andrew McIntyre wrote:
>>
>>>
>>> On Sep 20, 2005, at 8:18 PM, Daniel John Debrunner wrote:
>>>
>>>> I would say that if the version of the 10.1 branch is 10.1.1.1 then a
>>>> fix should result in the bug being marked as fixed in '10.1.1.1
>>>> (unreleased version)'. Ie. correctly represent the version of when the
>>>> bug was fixed.
>>>>
>>>> Once 10.1.2 is released (or maybe a release candidate) then any bugs
>>>> fixed in 10.1 since the last release could *also* be marked fixed in
>>>> '10.1.2 (released version)', not replace the fixin of 10.1.1.1. This
>>>> additional fixin is to link the bugs with the release and helps the
>>>> release notes generation.
>>>
>>>
>>> My only problem with this is that eventually you will end up with scores
>>> of unreleased versions in the bug tracking system. If we're not ever
>>> planning on releasing that version, why bother having a number for it at
>>> all? Why not just bump the version on the branch to 10.1.2.0 now and
>>> start marking all of the bugs fixed in 10.1.2.0, since we've already
>>> agreed that that's the next version we're actually going to officially
>>> release?
>>
>> Good points, but remember that we (the Derby project) may not be the
>> only group making a release. Anyone, this being open source, can make a
>> version of Derby for their own purposes, e.g. to redistribute within
>> their company. Thus those version numbers can represent a period of time
>> for the branch.
>>
>>>
>>>> Changing history of a bug tracking system is generally a thing to avoid.
>>>
>>>
>>> So is clogging it up with meaningless values for the version numbers.
>>
>> I don't believe they are meaningless. They represent the version of the
>> branch at some point in time which may have been used by someone.
>>
>>> The bigger issue is that we don't really know what that fourth position
>>> means. It doesn't seem to mean bugfix release, since it appears we've
>>> agreed that's what the third value represents. If we're not ever going
>>> to release a version that uses it in a meaningful way, then what is it
>>> doing there?
>>
>> For a branch I would say (using 10.1 as an example)
>>
>> - bump fourth digit at least after every snapshot, release candidate or
>> release
>> - bump third digit for the first candidate of a release
>>
>> 10.1.1.0 Initial release
>> 10.1.1.1 bumped after release
>> 10.1.1.2 bumped after snapshot (of 10.1.1.1)
>> 10.1.1.3 bumped after snapshot (of 10.1.1.2)
>> 10.1.2.0 release candicate one for 10.1.2
>> 10.1.2.1 bumped after rc1
>> rc1 goes for voting, some issues & fixes made to the branch
>> 10.1.2.1 release candicate two for 10.1.2
>> 10.1.2.2 bumped after rc2
>> rc2 accepted as official 10.1.2 release, its version is 10.1.2.1
>>
>> (and similar release candidate version changes could happen on the
>> intiial release, but I matched what is in 10.1 at the moment).
>>
>> Dan.
>>
>>
>>
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.344 / Virus Database: 267.11.3/107 - Release Date: 2005/09/20
>>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 2005/09/23
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 2005/09/23
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 2005/09/23
|