0004904: Status value per version within a project - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0004904	mantisbt	feature	public	2004-11-24 13:10	2012-11-01 07:45

Reporter	gtomlin	Assigned To	dregad
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	no change required
Product Version	0.19.0

Summary	0004904: 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.
Tags	No tags attached.

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 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 2011-06-21 04:43 reporter ~0029045	This is my first note

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.

View Issue Details

Activities