+1 good idea!
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
What Redmine version do you use?
See #8572.
--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------
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.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
+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)
--------------------------------------------------------------------------------
I've created a small patch (for version 3.2), which just adds an "archived" status to versions.
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")

--------------------------------------------------------------------------------
As suggested in #23855#note-2, there could also be a difference in "open" versions.
F.e. there is a difference between version#32 (which will never be released) and version#99 (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 |
--------------------------------------------------------------------------------
+1 and +1 for Wim's suggestion.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
+1 and +1 for Wim's suggestion.
--------------------------------------------------------------------------------
Mischa's comments in message#51751 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, 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)
--------------------------------------------------------------------------------
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 :-)
--------------------------------------------------------------------------------
I've updated the patch, so the new version status is called "released" (between "locked" and "closed").
It works against 3.4.x
--------------------------------------------------------------------------------
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.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,Closed,23265,Group versions by status in version custom field filter
relates,Closed,23855,Target version filter should get an entry 'All open versions'
relates,New,23858,Add another version status 'planed'
relates,New,17907,Give 'version' another meaning
relates,New,12982,Add status 'active' to versions
relates,New,16188,Mark project categories as "inactive"