View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004058 | mantisbt | bugtracker | public | 2004-07-09 10:08 | 2019-01-11 06:34 |
Reporter | nuclearspike | Assigned To | vboctor | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Fixed in Version | 0.19.0a2 | ||||
Summary | 0004058: Bug should be associated with a version by reference | ||||
Description | Currently, bugs are associated with a "fixed in" by placing the text of that version in the bug table. While making faster queries, by having a product_version_id link to the version table instead, there would be some benefits. When we fix something it's basically goes into the "next release" fix, whatever that version may end up being. Sometimes we may be building version 4.0.4.3 as the next one with a number of new features, but an emergency comes up and we put out a release that is called 4.0.4.3 (since the last release was 4.0.4.2) but it doesn't have all the other features. If we were associating with a "next public release" (or "july release", the version # not yet known), then once we released it, we would just rename that version to whatever it was when it was released and all bugs that were fixed in that release would have the 4.0.4.4 associated with it. recap: Our version #s get bumped every time something leaves our office - sometimes happening for emergency reasons, we'd like to be able to associate with the abstract "next minor release" without locking it to an exact version number yet. Our process would then be to rename "next minor release" to "4.0.4.4" and create another version named "next minor release". | ||||
Tags | No tags attached. | ||||
This will require a schema change and upgrade process. It may also slow things down as there will be an additional database lookup. I'll look into this in more detail. |
|
Currently fields like category and version are not using foreign keys, the values are written directly in the bugs table. However, Mantis software aims to always maintain these values in sync with the values in the categories or versions table. I think we are looking at two issues here:
I think you are mainly concerned about the first point which is doable now. If you call a version NextMinor, then associate issues with it in terms of "Fixed in Version". Later on, you assign it version number 1.2.3.4, you can go to the Manage Projects page, click the project, and rename the version name. This will automatically change the name of this release in all issues in both the "Fixed in Version" as well as "Product Version" fields. |
|
I am almost re-writing the version handling to do the following:
|
|
See 0004066 which I committed today. This includes support for future versions and a description field for versions. |
|
fixed in Mantis 0.19.0-CVS, this issue can be closed |
|
add fixed in information |
|