The version should get a status archived like projects
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
This could reduce the list of versions in the issue drop down fields.
#4 Updated by Nils Grimm about 2 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.
#5 Updated by Nils Grimm about 2 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.
#8 Updated by Wim DePreter almost 2 years ago
- File version_status_archived.patch added
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.
- 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")
#9 Updated by Wim DePreter over 1 year 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.
|Locked||version to release|
|Archived||released version, no more supported|
#15 Updated by Wim DePreter about 1 year ago
Mischa's comments inmade 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, like
Open > 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)
#16 Updated by Pavel Kveton about 1 year 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 :-)
#18 Updated by Robert Schneider 8 months 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.