View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004904||mantisbt||feature||public||2004-11-24 13:10||2012-11-01 07:45|
|Status||closed||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0004904: Status value per version within a project|
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.
|Tags||No tags attached.|
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.
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:
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.
This is my first note
In 1.2.x, versions have 2 flags 'released' and 'obsolete' which I think satisfies this requirement.
|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|