Project

General

Profile

Actions

Feature #21577

open

The version should get a status archived like projects

Added by Nils Grimm almost 9 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Custom fields
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
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.


Files


Related issues

Related to Redmine - Feature #23265: Group versions by status in version custom field filterClosedJean-Philippe Lang

Actions
Related to Redmine - Feature #23855: Target version filter should get an entry 'All open versions'Closed

Actions
Related to Redmine - Feature #23858: Add another version status 'planed'New

Actions
Related to Redmine - Feature #17907: Give 'version' another meaningNew

Actions
Related to Redmine - Feature #12982: Add status 'active' to versionsNew

Actions
Related to Redmine - Feature #16188: Mark project categories as "inactive"New

Actions
Actions #1

Updated by Tobias Fischer almost 9 years ago

+1 good idea!

Actions #2

Updated by Toshi MARUYAMA almost 9 years ago

  • Category changed from Issues planning to Custom fields
Actions #3

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.

Actions #4

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.

Actions #5

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.

Actions #6

Updated by Toshi MARUYAMA almost 9 years ago

  • Status changed from Needs feedback to New
Actions #7

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)

Actions #8

Updated by Wim DePreter over 8 years 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")
Actions #9

Updated by Wim DePreter about 8 years 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
Actions #10

Updated by Robert Schneider about 8 years ago

+1 and +1 for Wim's suggestion.

Actions #11

Updated by Toshi MARUYAMA about 8 years ago

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

Updated by Toshi MARUYAMA about 8 years ago

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

Updated by Toshi MARUYAMA about 8 years ago

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

Updated by Pavel Kveton almost 8 years ago

+1 and +1 for Wim's suggestion.

Actions #15

Updated by Wim DePreter almost 8 years 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)

Actions #16

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

Actions #17

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

Actions #18

Updated by Robert Schneider over 7 years 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.
Actions #19

Updated by Toshi MARUYAMA over 7 years ago

Actions #20

Updated by Wim DePreter over 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.

Actions #21

Updated by Go MAEDA almost 5 years ago

Actions #22

Updated by Mischa The Evil about 3 years ago

  • Related to Feature #16188: Mark project categories as "inactive" added
Actions

Also available in: Atom PDF