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:25:26 GMT
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


Mime
View raw message