View Issue Details

IDProjectCategoryView StatusLast Update
0004058mantisbtbugtrackerpublic2019-01-11 06:34
Reporternuclearspike Assigned Tovboctor  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version0.19.0a2 
Summary0004058: 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".

TagsNo tags attached.

Activities

thraxisp

thraxisp

2004-07-09 10:46

reporter   ~0005962

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.

vboctor

vboctor

2004-07-10 18:54

manager   ~0005975

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:

  1. Ability to rename a version that then reflects on issues / changelog / ...etc.
  2. How to link to versions / categories / ...etc?

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.

vboctor

vboctor

2004-07-10 23:45

manager   ~0005976

I am almost re-writing the version handling to do the following:

  • Add version_id as a primary key (however, this will not be used to refer to versions).
  • Support "released" flag, this will determine whether a version is a released version or a future versions. Product version field will only show released versions, but "fixed in version" will show all.
  • Added description field, and show it in Changelog before the actual list of entries.
  • Use version_id in the edit/delete version pages to refer to a specific version.
  • Use version_id in the version_api.
  • Use a version information class in version_api.
  • Support caching in versions_api.
vboctor

vboctor

2004-07-11 02:52

manager   ~0005981

See 0004066 which I committed today. This includes support for future versions and a description field for versions.

nuclearspike

nuclearspike

2004-07-14 09:55

reporter   ~0006042

fixed in Mantis 0.19.0-CVS, this issue can be closed

thraxisp

thraxisp

2004-07-19 20:51

reporter   ~0006164

add fixed in information