View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0013147 | mantisbt | feature | public | 2011-07-14 09:50 | 2017-01-18 16:56 |
Reporter | toddpw | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | 1.2.5 | ||||
Summary | 0013147: I really want true global versions (like global categories) | ||||
Description | I just spent a few hours tonight which should have been minutes because there is not true global version support. The subproject inheritance is great, but we have many projects with a few subprojects each, so the only way I can have the same list of versions across our whole installation is to use Copy Versions every time I add a version, and woe be to anyone who RENAMES versions, which is what I just had to do tonight. You either rename each version in every project in which it appears, or you delete the old ones (one at a time!) and copy the new ones over. It's VERY tedious, and I've burned up quite a few version ID numbers just tonight. | ||||
Steps To Reproduce | Have lots of projects. | ||||
Tags | No tags attached. | ||||
I see 0009197 has been closed. The auto-inheritance for subprojects is great, but without a global set of versions to inherit in the top-level projects, I am still looking at a ferocious amount of effort to maintain a large VERSION x PROJECT matrix. All our versions are consistent across the various projects, but they do slip and get rearranged, so about the only thing I could do to workaround the existing state of things would be to keep version names very vague and put all the information in the scheduled date. |
|
I would very much like to see this added too. Versions should be treated in exactly the same way categories are. Ie: there should be a mantis_version_table just like the mantis_category_table. I can understand the intention why this hasn't been added yet - if you require the same set of versions for multiple 'products' or 'projects', they are most likely released together and thus you could create a 'super-project' and attach all 'sub-projects' to this. For various reasons I would not opt for this resolution, one being that this would negate the use of the 2 seperate project-dropdownlists, as the first one would only be occupied by this topmost project, and the latter would then always contain all projects. |
|
It's only my opinion but it seems that the super-project solution is the right one for the problem described. The issue with the 2 project dropdowns is a smaller UI problem which could be solved with a better UI design. |
|
You're right. I moved those projects under the main project. As far as usability concerns a less beautiful solution, but functionally correct. |
|
There is another problem with global versions (also 1.2.5). I hope the description is ok and understandable. |
|