Feature #21577

The version should get a status archived like projects

Added by Nils Grimm almost 2 years ago. Updated 5 months ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Custom fields
Target version:-
Resolution:

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.

version_status_archived.patch Magnifier (2.2 KB) Wim DePreter, 2016-04-15 13:53

version_status_released.patch Magnifier (2.78 KB) Wim DePreter, 2017-07-13 08:16


Related issues

Related to Redmine - Feature #23265: Group versions by status in version custom field filter Closed
Related to Redmine - Feature #23855: Target version filter should get an entry 'All open versi... Closed
Related to Redmine - Feature #23858: Add another version status 'planed' New
Related to Redmine - Feature #17907: Give 'version' another meaning New

History

#1 Updated by Tobias Fischer almost 2 years ago

+1 good idea!

#2 Updated by Toshi MARUYAMA almost 2 years ago

  • Category changed from Issues planning to Custom fields

#3 Updated by Toshi MARUYAMA almost 2 years ago

  • Status changed from New to Needs feedback
  • Priority changed from High to Normal

What Redmine version do you use?
See #8572.

#4 Updated by Nils Grimm almost 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 almost 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.

#6 Updated by Toshi MARUYAMA almost 2 years ago

  • Status changed from Needs feedback to New

#7 Updated by Wim DePreter over 1 year 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)

#8 Updated by Wim DePreter over 1 year ago

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")

#9 Updated by Wim DePreter about 1 year ago

As suggested in #23855#note-2, there could also be a difference in "open" versions.
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

#10 Updated by Robert Schneider about 1 year ago

+1 and +1 for Wim's suggestion.

#11 Updated by Toshi MARUYAMA about 1 year ago

  • Related to Feature #23265: Group versions by status in version custom field filter added

#12 Updated by Toshi MARUYAMA about 1 year ago

  • Related to Feature #23855: Target version filter should get an entry 'All open versions' added

#13 Updated by Toshi MARUYAMA about 1 year ago

  • Related to Feature #23858: Add another version status 'planed' added

#14 Updated by Pavel Kveton 11 months ago

+1 and +1 for Wim's suggestion.

#15 Updated by Wim DePreter 11 months ago

Mischa's comments in RE: version status for "sunset" versions 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)

#16 Updated by Pavel Kveton 11 months 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 :-)

#17 Updated by Wim DePreter 5 months ago

I've updated the patch, so the new version status is called "released" (between "locked" and "closed").
It works against 3.4.x

#18 Updated by Robert Schneider 5 months ago

My 2 cents:

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

#19 Updated by Toshi MARUYAMA 4 months ago

Also available in: Atom PDF