0008360: Multiple "Fixed in Version" per bug - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0008360	mantisbt	relationships	public	2007-09-14 13:05	2009-06-26 12:01

Reporter	davidnewcomb	Assigned To	vboctor
Priority	normal	Severity	feature	Reproducibility	N/A
Status	closed	Resolution	won't fix

Summary	0008360: Multiple "Fixed in Version" per bug
Description	We have about 4 major versions of our code base 2.0, 3.0, 3.5, 3.6. Often a bug will appear in several code bases. Could we have the ability to say that a bug has to be fixed in more than one release. Also that bug will be fixed in different versions eg 2.0.12, 3.0.4, 3.5.6, 3.6.1. Some users clone the bug 4 times to do this, but I feel this is a work around. It means that each bug has 4 numbers. You must then 'try' to have a policy on which one gets the bugnote updates. Statuses would have to be something like Fixed, DoseNotApply, WontFix - or something. Only when all the revisions have been accounted for then the bug can be closed.
Tags	No tags attached.

Hauptmann 2007-11-20 05:09 reporter ~0016247	We have the same problem. Although mostly only 2 versions at the same time

jensberke 2008-10-13 05:03 reporter ~0019540	I consider this a very good idea as well and would love to have that feature. It could be pretty simple: just provide multiple fields for "Product version", "Target version" and "Fixed in version" respectively. All versions given in these fields for a bug report should make the bug appear in the roadmap and changelog for each version.

steffel 2009-01-21 11:22 reporter ~0020672 Last edited: 2009-01-21 11:22	we are also interested in that feature, but i think it's not that easy as it seems... the dependency issues <-> projects result in a n:m relationship that affects database architecture as well. or it will be solved in a dirty way that the target version string will be used as container ... (i prefer the clean solution...)

brianstv 2009-03-13 12:06 reporter ~0021042	If this feature is ever implemented, be sure it can be disabled in configuration. Coming from using a defect tracking system that allowed multiple project-versions per issue, it gets difficult to report on and track which versions actually got fixed, and if using source control integration, even more difficult. We have opted for one project-version per issue, relating the issues where needed.

jreese 2009-03-13 13:44 reporter ~0021043	For those running the development 1.2.x version, I have a work-in-progress plugin that allows you to assign a bug status to multiple products, each which may have multiple versions. It allows my employer to track a bug against multiple interleaving products, and against multiple versions of each product that may share the same code/bug. It also changes the meaning of the existing versions system to "milestones", and allows the set of products and versions to exist across all the various projects. http://git.mantisforge.org/w/product-matrix.git

vboctor 2009-05-31 14:58 manager ~0022009	Glad to see a plugin that addresses this issue. I don't think we will implement this in MantisBT. However, we should attempt to make it easy to clone+resolve for each fix. I believe the current model is simpler and works better to understand when check-ins are done on different branches. In some cases the fixes and discussions may also be different per version. This also works better with other features like filters, changelog, roadmap, etc.