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 trough a few iterations it generated a lot of different versions in the wild. To make matters worst : 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.

End result 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 practice 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).

Answer 2

I use Bugzilla to keep track not only of bugs, but also of new features, enhancements, and vague ideas. For each planned and released version, I have a Tracking Bug (something that I saw on the original Mozilla bugzilla, and found to be useful).

So if you have a bug report, you enter the bug with the version number that it was reported. Create additional bugs (one for each version you plan to fix it in) which all depend on (block) the original bug and block the version-specific Tracking Bugs.

If all bugs blocking the original bug are closed/verified (whatever your QA implements), you can also close the original bug.

Answer 3

We just switched to JIRA ;)

Answer 4

We are using jira and still have this problem. I think it is a question of requirements and how are versions used rather than any one tool.

Who uses versions and how do they use them?
How are versions related to milestones in a project plan?

We use a 4 dectet version (major.minor.patch.buildNO). buildNo is the SVN head revision # at time of build. Each version is stored in JIRA and issues have an affects version and fixed-in version field that's a multi select.

After a short while we have many versions. Jira does allow us to control the list in two ways 1. Archive versions (greyed out from pick list) 2. Merge versions (rolls several versions together into a new version - no undo)

We have used Archive, but have avoided Merge due to the lack of the undo. So we still have a list of many many versions.

I'm sure you could probably accomplish a merge action in Bugzilla with some scripting and time, the question is: when is it OK to merge several older versions together?

If I have released, do I need to know that I have 17 builds between start and release? Do I need to keep the knowledge of a bug being found in build 1, fixed in 2, found again in 7, fixed again 9? Or is Found in release 1.0.0 fixed in release 1.0.1 good enough?

i'm going to ask a large question on this topic later on today, but I know the basic answer already: - Depends on how your team wants to track things.

Implementation is fun, but it all comes down to requirements, goals and working back from user experience to solution. Which is rough when people don't necessarily know how that want to use something that doesn't quite exist in the form they'd like to use.