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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Daniel John Debrunner" <[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
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
