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

Reply via email to