125283 - Create a sub-version field

Status: RESOLVED WONTFIX

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Stuart Meisel]

It seems to me that Bugzilla could use an additional Version No. field.

At this time, you cannot easily report a bug against one version number and 
Verify/Close it against a different version number.  (For Example, report a 
bugs against Version 2.02.01 and fixing against 5.02.00.)  You can choose a 
version number against which you report a bug, or you can change a bug's 
version number, for example, to the Version against which the bug was tested 
and Verified/Closed.  But you cannot easily identify a Version number against 
which bug was identified, and a different Version number against which it was 
Verified/Closed.

I think that this feature could provide some features that could be very useful 
in the management of bugs:
  -  Audit trail
  -  Number of releases that the bug remains unfixed.  (I am reminded here of a 
process similar how invoices are "aged.")

Reports using these two fields could specify how many versions of software were 
created between the time of Bug Identification and:
  --->  Bug resolution;
  --->  Current software version.

Time differences may not meet the requirements because it could be short times 
but lots of new version numbers.

Thoughts??

Comment 1

[Dave Miller [:justdave]]

In both of the installs that I've had a need for this feature, we've used the
Target Milestone field for this purpose.  It serves as a target for what version
we plan to fix it in while the bug is open, and should be set to the version
it's actually fixed in once the bug is resolved.

I've seen enough comments on this that maybe an explicit (optional) field for
this would be good to have.  Although that might be able to be provided by bug
91037.

Comment 2

[Jeroen Ruigrok van der Werven]

This is something I was thinking off yesterday, subversion integration that is 
and today got asked by another user on the subversion list.

Dave, your comment with regard to the milestone does not work for branches, 
where you backport certain fixes to a previous release.  At least AFAIK (As Far 
As I Know) you cannot specify two milestones to a report.

Only thing I am wondering about is how to properly do 'integration'.  I myself, 
for example, am only interested in matching version number with bug number.  No 
need for audit trails in the commit messages.

Comment 3

[Don Norton]

While the target_milestone field can be used for this purpose, it would be nice 
to have an explicit field visible (whether optional or not) to support this 
concept.  It's very common for a bug to be identified in a release, but not 
fixed until a few releases later.  Auditing/collecting bugs fixed in a given 
release is made more challenging without this field.  

It would be nice to have an option requiring this field be set before a bug is 
marked FIXED.

Comment 4

[Frédéric Buclin]

*** Bug 127276 has been marked as a duplicate of this bug. ***

Comment 5

[Philipp Schumann]

We have a case where we have milestones that are not the same as versions. i.e.
we have a milestone "direct flights" and a milestone "via flights" (and several
others) But it would be very helpful if we had a "fixed with version" field for
all the bugs that are reported within a milestone.

Comment 6

[Andre-John Mas]

I have used ClearCase/ClearQuest at a company I work for and it provides the functionality for associating a checkout with an assigned issue. That way when you look at the bug entry you can tell straight away which files where changed/added/deleted ans at what version.

Could be nice to have for Bugzilla with subversion, though as an option of course.

Comment 7

[M. Creidieki Crouch]

A good user-interface on this could really reduce the number of useless comments on bugs.  Right now, a bug can be marked "FIXED" but still be present in the latest enduser version.  That's very confusing, and a user currently has to read through all of the comments to figure out whether they're still experiencing the same bug.

Comment 8

[Max Kanat-Alexander]

We won't be fixing this upstream, but you can currently implement it in 3.0 with drop-down or plain-text custom fields.

Comment 9

[bigstijn]

It's a bit a pitty this won't get upstream.  Bugzilla.Mozilla.Org has it now, no?

Anyhow, comment 8 is not the whole truth: we'll need bug 371995, as every product has it's own version history.