View Issue Details

IDProjectCategoryView StatusLast Update
0004904mantisbtfeaturepublic2012-11-01 07:45
Reportergtomlin Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Product Version0.19.0 
Summary0004904: Status value per version within a project
Description

Currently a given project has one status and several versions. For ourselves, and I'm sure many others, a given project may have several versions, one or more of which is in development, possibly one in alpha or beta test, several which have already been released, and several which are obsolete and no longer supported. So basically I think that the status field is in the wrong place.

When an issue arises, it can affect several versions of a project, so separating the versions into different projects would not appear to be the answer.

I would like to be able to indicate the current status of each version. It would also be nice, although less important, to be able to associate dates with each version (first customer ship, generally available, obsoleted, etc.).

Among other things, this could be used to block the reporting of issues against obsolete/unsupported versions, and would provide a handy quick reference for version status.

TagsNo tags attached.

Activities

thraxisp

thraxisp

2004-12-01 11:40

reporter   ~0008479

One way to do this now would be to "Clone Issue" for future releases. This way you could have a related issue tracked for each pending release.

gtomlin

gtomlin

2004-12-01 12:58

reporter   ~0008485

Last edited: 2004-12-01 13:16

Hmm, I don't think cloning issues answers this at all. I probably didn't express myself clearly. I'll make up a scenario here to illustrate.

Suppose I have a product/project with versions 1, 2, 3, 4, 5 and 6, and:

  • versions 1 and 2 are obsolete and no longer supported;
  • versions 3 and 4 are generally available production versions;
  • version 5 is under development and has not been released;
  • version 6 is a future release that is not yet under development.
    Because versions 1 and 2 are unsupported, I would want to prevent issues from being reported against them.

As Mantis currently (or as of 0.19.0, which I'm running) works, I have to give the product as a whole a status of either development, release, stable or obsolete. Clearly this status value cannot accurately represent the status of all the versions of the product. From that point of view, I am suggesting that the status value be moved from the project definition to the project version definition. This would more accurately represent reality and would enable some nicer configurability as to what releases it is possible to report issues against.

Right now, if I were to describe the above scenario to Mantis, I would need to mark versions 1, 2, 3 and 4 as released and versions 5 and 6 as not released. I could prevent issues from being reported against 1 and 2 by "lying" and marking them not released. Similarly I could allow issues to be reported against 5 by lying and marking it released.

If the status was moved from the project to the version, then it would be possible to add config variables to allow an installation to specify whether issues can be reported against versions in different states. For example, in my installation I would like to be able to report issues for versions that have not yet been released, and I would like to prevent issues from being reported for versions that are no longer supported.

Edit: this might tie in nicely with the changes proposed in 0004218.

sohag

sohag

2011-06-21 04:43

reporter   ~0029045

This is my first note

dregad

dregad

2012-10-18 08:47

developer   ~0033264

In 1.2.x, versions have 2 flags 'released' and 'obsolete' which I think satisfies this requirement.

Issue History

Date Modified Username Field Change
2004-11-24 13:10 gtomlin New Issue
2004-12-01 11:40 thraxisp Note Added: 0008479
2004-12-01 12:58 gtomlin Note Added: 0008485
2004-12-01 13:16 gtomlin Note Edited: 0008485
2011-06-21 04:43 sohag Note Added: 0029045
2012-10-18 08:47 dregad Note Added: 0033264
2012-10-18 08:47 dregad Status new => resolved
2012-10-18 08:47 dregad Resolution open => no change required
2012-10-18 08:47 dregad Assigned To => dregad
2012-11-01 07:45 atrol Status resolved => closed