db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TomohitoNakayama" <tomon...@basil.ocn.ne.jp>
Subject Re: 10.1.2 Release status page
Date Sat, 24 Sep 2005 14:30:27 GMT
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


Mime
View raw message