View Issue Details

IDProjectCategoryView StatusLast Update
0004218mantisbtrelationshipspublic2009-06-13 04:10
ReporterDGtlRift Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Product Version0.19.0a2 
Summary0004218: Issue found/fixed & version/build relationships with Changelog
Description

When we go to a new version, we split the code (let's say version 3.0 (patch 14) to 4.0 (patch 0)) so that we can start including new core features in the 4.0 version. The issue arrises when a few months later an issue is found in version 3.0p15, and testers have found that it goes back to before the code split so it is also in version 4.0p2.

So it is possible to have the same bug in multiple versions, and fixed at diffrent patch levels for those versions.

If version and fixed_in_version were dependancy keys on another table for a join, that could give the versions the issue was confirmed/fixed in for multiple major versions.

In addition, the build (what we use to indicate patch-level) could also be used for this information if instead of being in the mantis_bug_table it
was in a mantis_project_version_build_table that would be tied to mantis_project_version_table so that builds could be enumerated against versions.

This would also allow for (thanks to Wanderer for the suggestion) the possibility for multi-level ChangeLog where the ChangeLog could show:
First level - Fixed in version
Nested - Fixed in build

Additional Information
+------------------------------+ mantis_project_version_table +---+-------------+------------+ K id 1:M >>-------\ project_id \ version \ date_order \ description \
+---+-------------+ \
\
+------------------------------------+
mantis_project_version_build_table +---+----------+---------------------+ / versioID M:1 <-----------------/ K id 1:1 <----------\ buildStr \
+---+----------+ \
+---------------------------+
mantis_bug_versions_table

+---+--------------+--------+ /
| K | verbuild_ID | 1:1 >>------/
| K | bug_ID | M:1 <-----\
| | foundORfixed | \
+---+--------------+ \
\
+------------------+ |
| mantis_bug_table | |
+---+--------------+----+ |
| K | id | 1:M >>--/
| | ... |
+---+-------------------+

This could be the relationships between the tables. I think this would work, but I'm not sure how much code change would be involved. The foundORfixed entry would just be a boolean type to indicate if it was ... well, fixed or found. I didn't think it should be a key since I don't think it is possible to find and fix a bug in the same version (unless it is not a bug, or wont be fixed.)

TagsNo tags attached.

Relationships

related to 0003638 closedvboctor the bugtracker should be able to produce a changelog 
related to 0004841 closedatrol We should be able to report the version,revision and build where the bug occured. 
related to 0006593 closedgrangeway Allow a bug to be resolved for multiple versions 
child of 0004181 closed Features in Mantis 1.1 release 

Activities

DGtlRift

DGtlRift

2004-07-29 09:07

reporter   ~0006438

Last edited: 2004-07-29 11:47

Ack... My relationship diagram fell apart in the additional comments... but I think you should be able to cut and paste it to view the fixed type font... OR are there tags to include into submission that would force text to be fixed type?

This is related to issue 3638

<pre>
+------------------------------+
mantis_project_version_table +---+-------------+------------+ K id 1:M >>-------\ project_id \ version \ date_order \ description \
+---+-------------+ \
\
+------------------------------------+
mantis_project_version_build_table +---+----------+---------------------+ / versioID M:1 <-----------------/ K id 1:1 <----------\ buildStr \
+---+----------+ \
+---------------------------+
mantis_bug_versions_table

+---+--------------+--------+ /
| K | verbuild_ID | 1:1 >>------/
| K | bug_ID | M:1 <-----\
| | foundORfixed | \
+---+--------------+ \
\
+------------------+ |
| mantis_bug_table | |
+---+--------------+----+ |
| K | id | 1:M >>--/
| | ... |
+---+-------------------+
</PRE>

Thnx thraxisp

edited on: 07-29-04 11:47

thraxisp

thraxisp

2004-07-29 10:10

reporter   ~0006439

Last edited: 2004-07-29 10:11

(Note: Text fields do support the HTML {pre}{/pre} construct.)

edited on: 07-29-04 10:11

siebrand

siebrand

2009-06-13 04:10

developer   ~0022129

Unassigned after having been assigned for multiple years without progress.

Issue History

Date Modified Username Field Change
2004-07-29 09:03 DGtlRift New Issue
2004-07-29 09:07 DGtlRift Note Added: 0006438
2004-07-29 09:14 DGtlRift Note Edited: 0006438
2004-07-29 10:10 thraxisp Note Added: 0006439
2004-07-29 10:11 thraxisp Note Edited: 0006439
2004-07-29 11:47 DGtlRift Note Edited: 0006438
2004-07-30 08:22 vboctor Relationship added related to 0003638
2004-09-03 06:17 DGtlRift Assigned To => DGtlRift
2004-09-09 12:09 dwlnetnl Sponsorship Added dwlnetnl: US$ 5
2004-09-09 12:09 dwlnetnl Sponsorship Total 0 => 5
2004-11-12 06:10 DGtlRift Relationship added related to 0004841
2004-11-12 06:15 DGtlRift Relationship added child of 0004181
2004-11-12 06:16 DGtlRift Status new => acknowledged
2007-05-15 14:41 DGtlRift Relationship added related to 0006593
2009-06-13 04:10 siebrand Note Added: 0022129
2009-06-13 04:10 siebrand Assigned To DGtlRift =>
2009-06-13 04:10 siebrand Status acknowledged => new