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|
|Target Version||Fixed in Version|
|Summary||0013147: I really want true global versions (like global categories)|
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 <i>all</i> 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.
|2011-07-14 09:50||toddpw||New Issue|
|2011-07-14 09:53||toddpw||Note Added: 0029168|
|2011-09-05 10:22||dhx||Relationship added||related to 0009197|
|2011-09-16 18:56||vincent_sels||Note Added: 0029761|
|2011-09-19 22:06||djcarr||Note Added: 0029807|
|2011-09-20 11:37||vincent_sels||Note Added: 0029814|
|2012-06-22 04:48||fbraun||Note Added: 0032139|
|2012-06-22 04:56||dregad||Note Added: 0032140|
|2012-06-22 04:56||dregad||Relationship added||related to 0005668|
|2017-01-18 16:56||atrol||Severity||major => feature|