Open Bug 79964 Opened 24 years ago Updated 7 years ago

More than one version per bug

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

2.10
enhancement

Tracking

()

People

(Reporter: nn4l, Unassigned)

References

Details

I would like to select more than one version per bug. For example, if a severe problem is discovered in a beta version, I usually verify the problem with the current production version. If the problem exists there too, I want to make it visible in queries both for the current beta version and for the old version which is in production. I think it is a frequent problem that identical bugs must be addressed in different versions. There should be a way to deal with this. I could easily do this if I could select more than one version per bug. Another approach would be to duplicate the bug record and process it independently for both versions, but usually I do not want to duplicate data if I can avoid it.
Target Milestone: --- → Future
-> Bugzilla product
Assignee: tara → justdave
Component: Bugzilla → Bugzilla-General
OS: Windows NT → All
Product: Webtools → Bugzilla
Hardware: PC → All
Version: Bugzilla 2.10 → 2.10
What's the status on this ?
There's no status on this - no one has stepped up to do anything about it. Bug #91037 may well bring us closer to it though.
i suggest to change status of this bug to WORKSFORME, because it's more a question of quering (IMO - bug should be applied to the earliest known version, so, when you search, you find bugs specific to that version, but, of course, it is a matter of style :) )
Reassigning all of my "future" targetted bugs to indicate that I'm not presently working on them, and someone else could feel free to work on them. (sorry for the spam if you got this twice, it didn't take right the first time)
Assignee: justdave → nobody
Summary: [RFE] need more than one version per bug → More than one version per bug
*** Bug 232851 has been marked as a duplicate of this bug. ***
We often need to maintain multiple revisions of our product at the same time. Many times, many versions of the product need to have a bug fixed. Currently, the only way we can do that in bugzilla is to create multiple bugs which tends to be ugly since there is often the same resolution to several versions.
In our case, we often decide to fix bugs differently in different versions.. and so we need a different status per bug per version.
We have sort of resolved this issue by using flags. We create a flag from every version of our product. If you think of flags a generic 4 state field then you can do this: (null): bug is not associated with this revision ?: bug might be associated with this revision, further analysis required -: bug exists in this revision and was not fixed +: bug existed in this revision and was fixed This is kind of a hack, since we can't use the post "resolved" states of bugs to track verification or anything - but it gets us to a usable solution.
Flags are good for workflow type of scenarios, but they do not help in the case that a bug may be in a different state in different releases. It is often the case at my company that bugs have a workaround in a specific release, but a complete fix in a different release. We cannot represent that information with flags.
Flags alone may not work, but there are ways to achieve what you're looking for with the current state-of-the-Bugzilla. One way to accomplish it would be as follows: 1) Create a set of flags for each platform; comment #9 shows one such way. 2) Create a set of 'version' flags that match your release names. 3) When a bug is found, an initial bug report is created with the Version and Platform set to indicate where the problem was identified. 4) Set the flags on the bug to '?' for each platform, until you've either fixed the bug or identified for sure that it does not exist on this platform. 5) Use the newly-created 'Clone This Bug' functionality (bug 81642) to create a duplicate of the first bug report. Set the version differently; this will become the tracking bug for this issue in that version. 6) Repeat step #4 for this newly-created bug. 7) Repeat steps #5-6 for each version you're supporting. It may seem a little kludgy, but it can be done, and without resorting to O(n^2) flags either.
*** Bug 333429 has been marked as a duplicate of this bug. ***
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Future → ---
Blocks: bz-branch
For what it's worth, this could be emulated by a combination of bug 287330 and bug 308253.
Assignee: nobody → create-and-change
Component: Bugzilla-General → Creating/Changing Bugs
Depends on: 287330, 308253
Priority: -- → P3
No longer blocks: bz-branch
This is still a wanted feature.
You need to log in before you can comment on or make changes to this bug.