db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: 10.1.2 Release status page
Date Wed, 21 Sep 2005 13:28:45 GMT
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.





Mime
View raw message