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

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


----- 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 then a
>>> fix should result in the bug being marked as fixed in '
>>> (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 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 now and
>> start marking all of the bugs fixed in, 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
> Initial release
> bumped after release
> bumped after snapshot (of
> bumped after snapshot (of
> release candicate one for 10.1.2
> bumped after rc1
> rc1 goes for voting, some issues & fixes made to the branch
> release candicate two for 10.1.2
> bumped after rc2
> rc2 accepted as official 10.1.2 release, its version is
> (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

View raw message