Feature #21577
openThe version should get a status archived like projects
0%
Description
If the custom field type version
is used the list if versions can get very long.
Very old versions which the support has been stopped long time ago, should be settable to the status archived
.
This could reduce the list of versions in the issue drop down fields.
Files
Related issues
Updated by Toshi MARUYAMA almost 9 years ago
- Category changed from Issues planning to Custom fields
Updated by Toshi MARUYAMA almost 9 years ago
- Status changed from New to Needs feedback
- Priority changed from High to Normal
What Redmine version do you use?
See #8572.
Updated by Nils Grimm almost 9 years ago
I'm using the latest version 3.2.0.
Yes, I'm aware if the issue #8572.
But I think a new added version state like 'archived' would be great because the other states are already in use and have different meanings.
Why not adding the same state type to versions as projects are already having?
In the state 'archived' the version would be closed, too.
But for a long running projects with many versions this would give the option for the manager to remove the version out of the version list after a maintenance windows have run out or something similar.
So the 'archived' state would assigned to the oldest but no longer maintained versions.
Updated by Nils Grimm almost 9 years ago
And about the category change:
I don't think anything has to be done in the way the custom field is already working.
The issue #8572 already provide the necessary functionality for reducing the list.
I think only another version state type should be added.
Or the option to define additional custom version states for the administrator.
Updated by Toshi MARUYAMA over 8 years ago
- Status changed from Needs feedback to New
Updated by Wim DePreter over 8 years ago
+1
We are looking for a way to filter our "Affected Version" list, and status "archived" for no longer supported versions would be great.
Even redmine.org could apply this for the Affected Version (starts now with 0.7, which was released in 2008)
Updated by Wim DePreter over 8 years ago
An "archived" version is considered to be closed (f.e. in Roadmap), but custom "version" fields can make a distinction between "closed" versions and "archived" versions.
To do:
- adapt all locales
- possible improvement: make a distinction between "closed" and "archived" versions in the roadmap (f.e. add checkbox "View archived versions" + link "Archived versions")
Updated by Wim DePreter about 8 years ago
F.e. there is a difference between Candidate for next major release (which will never be released) and 4.0.0 (release in 2017?)
So if list of possible version-statuses is extended, maybe there should also be other "open" statuses.
F.e.:
New | unplanned version |
Open | planned version |
Locked | version to release |
Closed | released version |
Archived | released version, no more supported |
Updated by Toshi MARUYAMA about 8 years ago
- Related to Feature #23265: Group versions by status in version custom field filter added
Updated by Toshi MARUYAMA about 8 years ago
- Related to Feature #23855: Target version filter should get an entry 'All open versions' added
Updated by Toshi MARUYAMA about 8 years ago
- Related to Feature #23858: Add another version status 'planed' added
Updated by Wim DePreter almost 8 years ago
Mischa's comments in
made me think, and maybe "Archived" is not such a good version state, but we need a new state between "Locked" and "Closed" that indicates the version is shipped and "open" for reporting, likeOpen > Locked > Released > Closed
This way, you have an open/closed state before (for "Target Version": open/locked) and after (for "Affected Version": released/closed) release.
A closed version can be considered as a closed project, so no new issues can be reported for a closed version (custom field "Affected Version" must be configured by administrator to exclude closed versions)
Updated by Pavel Kveton almost 8 years ago
thinking about it, we probably don't really need the "New" version type - I use special version name in Open state instead and it is sufficient.
As for Open->Locked->Released->Closed suggested by Wim - this naming is closer what I'd understand under "Closed" version (i.e. not supported any longer), so I like it more than "Archived" status name.
But I don't care much about the naming, as long as the functionality is there :-)
Updated by Wim DePreter over 7 years ago
I've updated the patch, so the new version status is called "released" (between "locked" and "closed").
It works against 3.4.x
Updated by Robert Schneider over 7 years ago
My 2 cents:
- I would realize the 'New' status as well (or call it 'Planed' like in #23858). I don't find it appealing to use the name for that. IMO this is a workaround. Also because of then there is no chance to hide such versions from the roadmap. They pollute the roadmap (look at Remine's roadmap!). That state could also influence if (certain) users can add issues to it or not or for what not. No one is forced to use it, you can still use the name for that.
- Could we rename 'Released' to 'Completed' or something similar? Have a look at another issue of me: #17907. I still hope that Versions will be replaced by something different (at least the name), because we use Redmine not only for Software development, so 'Released' is not so suited if you think about e.g. Milestones.
Updated by Toshi MARUYAMA about 7 years ago
- Related to Feature #17907: Give 'version' another meaning added
Updated by Wim DePreter about 6 years ago
We are using Redmine now for more than 5 years (and we think it's great), but the number of closed versions, that are no longer supported, keeps on growing.
Please could the Redmine team reconsider to bifurcate the "closed" state into a "closed supported" and a "closed no longer supported" (or some other status name)
This would mean a lot to us, because users won't get a long list of versions when selecting the "affected version", but only the smaller list of supported versions, and it makes thus Redmine more user-friendly.
Updated by Go MAEDA over 4 years ago
- Related to Feature #12982: Add status 'active' to versions added
Updated by Mischa The Evil about 3 years ago
- Related to Feature #16188: Mark project categories as "inactive" added