How do you track versions in Bugzilla?

Question

We are in the process of migrating our bug tracking to Bugzilla from a really old version of track and I am running out of Advil.

We have a legacy application that has been around for a long time. Mix in the fact that our versioning management has been through a few iterations it generated a lot of different versions in the wild. To make matters worse, because of contractual limitations it is not always possible to upgrade the clients to the latest and greatest, so we must branch, fix, test and release, on the version they currently have, yielding yet another version number.

The end result is that the version combo box is ludicrously long. Lastly, for various reasons, we want to track three different version information : the version in which the bug was found (version), the version in which we plan to fix (milestone) the bug and the version in which it has ultimately been fixed (open to suggestions). here is my problem in fact... this can actually be multiple numbers where we did a retroactive fix for some of these customers (this happens VERY often).

This is where I need your collective wisdom :

How do you keep track of these versions (found, planned and multiple fixed) in Bugzilla?

What are the best practices around linking versions and bug tracking ?

---

Answers

It seems that cloning the bug for each version is a good way to track, thus the target version is always tracked in the milestone as well as the fixed version, and the buggy version is always the native version.

Also to have each clone block the original bug make it a good way to trace the history back to the original submission.

Although I have accepted the answer I still welcome your input.

Answer 1

Often, if we need to fix something in multiple released versions (generally branches in the source code repository), the bug will be cloned for each branch so that all the commits and release status can be tracked separately. I think the only time we don't do this is when the change is not directly related to the codebase itself and cannot be fixed simply by updating our libraries.

As for version tracking in general, this has struck me as a reasonable way to do things, given that we generally only need to support 2-3 major versions (plus the trunk) at any time. If you have multiple disjoint versions that need supporting, e.g. customer-specific deployments, then things are going to be harder to track. (Arguably this is going to cause headaches in general and it would be better to unify things to a more central version theme).