db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <mcintyr...@gmail.com>
Subject Re: 10.1.2 Release status page
Date Wed, 21 Sep 2005 03:58:14 GMT

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?

> 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.

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?

At Cloudscape, we bumped the last version whenever a fix was  
delivered to a customer, which was useful because if you delivered  
five fixes in a week, all five could have different version numbers  
with each new version representing the next fix. However, the Apache  
process for releases - posting a candidate, testing, and then voting  
- prevents the kind of turnaround on quick fixes that use to make  
that last position meaningful.

Perhaps we should either amend the version policy or figure out a way  
to make that last number mean something useful.

andrew

Mime
View raw message