version status for "sunset" versions

Added by Pavel Kveton almost 3 years ago

hi all,

I'm looking for a way how to mark a version in Project Settings -> Versions -> Edit as "sunset" so that it won't appear in "Found in version" and "Fixed in version" in the Issue definition dialog.

The use case is that we have a version of the software that is no longer supported, however, there are some issues assigned to this version (all closed).

Since there are some issues (even closed), it is not possible to delete the version (and I won't like to do it, anyway).

How can I say that the version is no longer supported (=sunset) so that it does not appear in the new issue dialogs anymore?

Does redmine allow something like this? (and if so, how)?

thanks a lot
Pavel

Replies (7)

RE: version status for "sunset" versions - Added by Wim DePreter almost 3 years ago

As far as I know, this is not available in plain Redmine.
There is a feature request for this: #21577

RE: version status for "sunset" versions - Added by Mischa The Evil almost 3 years ago

Pavel Kveton wrote:

[...] so that it won't appear in "Found in version" and "Fixed in version" in the Issue definition dialog.

FTR: core Redmine comes only with a 'standard field' called "Target version" (in English translations). Vanilla Redmine instances don't come with "Found in version" and "Fixed in version" fields. You can however configure additional custom fields (using project versions as their values) to use for eg. issues.

Pavel Kveton wrote:

The use case is that we have a version of the software that is no longer supported, however, there are some issues assigned to this version (all closed).

Since there are some issues (even closed), it is not possible to delete the version (and I won't like to do it, anyway).

How can I say that the version is no longer supported (=sunset) so that it does not appear in the new issue dialogs anymore?

Looking at the outline of your use case above, I think a combination of the features implemented through #1245 (see #1245#note-17, #1245#note-23 and #1245#note-47 for details) and #8572 (see #7443#note-33 for some details and a screenshot describing #8572 by Go MAEDA) provide you with the needed settings and configurations to setup an environment like you need.

Wim DePreter wrote:

As far as I know, this is not available in plain Redmine.
There is a feature request for this: #21577

Wim, can you please elaborate on why, in your opinion, such is not possible to configure with the current features provided by vanilla Redmine? I am aware of the content of #21577, but that seems to be all covering more specific use cases. The basics, of what the OP needs, seem implemented.

RE: version status for "sunset" versions - Added by Wim DePreter almost 3 years ago

Mischa The Evil wrote:

Wim, can you please elaborate on why, in your opinion, such is not possible to configure with the current features provided by vanilla Redmine? I am aware of the content of #21577, but that seems to be all covering more specific use cases. The basics, of what the OP needs, seem implemented.

Maybe I'm wrong, but for now, it is not possible to create a custom version field that only contains a subset of closed versions (i.e. the "supported" versions).
F.e. the "Affected version" on the Redmine website lists all closed versions, while the early versions (0.x.x) are no longer supported. The list of closed versions can get very long, so users have to scroll down to look for the more recent (and still supported) versions.

RE: version status for "sunset" versions - Added by Mischa The Evil almost 3 years ago

Wim DePreter wrote:

Maybe I'm wrong, but for now, it is not possible to create a custom version field that only contains a subset of closed versions (i.e. the "supported" versions).

No, you are not wrong. But I think that the primary subject of the OP's use case question is whether or not it is possible to configure the "targetability" of versions for issues (for both standard and custom fields). Specifically for that purpose we have #1245's features (closed/locked versions aren't targetable ie. don't show up in default 'target version' field) and building on those we gain control over whether those closed/locked version show up as possible values in custom fields with #8572.

Wim DePreter wrote:

F.e. the "Affected version" on the Redmine website lists all closed versions, while the early versions (0.x.x) are no longer supported. The list of closed versions can get very long, so users have to scroll down to look for the more recent (and still supported) versions.

True. And this is indeed covered by #21577 (and a range of others). However, it is IMHO something that is reaching beyond the scope of the OP's use case and question itself. Thereby my reply.

Please let me know if you think I'm wrong here in some way...

RE: version status for "sunset" versions - Added by Pavel Kveton almost 3 years ago

Hi all, thank you all for the answers - actually what I'm looking for is exactly #21577. I haven't found it before, so I'm sorry for posting the question while there was already this issue...

RE: version status for "sunset" versions - Added by Mischa The Evil almost 3 years ago

Pavel, I'm glad you've found the answer to your question anyways. Thanks for your feedback.

RE: version status for "sunset" versions - Added by Wim DePreter almost 3 years ago

Mischa The Evil wrote:

Please let me know if you think I'm wrong here in some way...

As a developper, I totally agree that current states are all that we need to develop and release a version. From a reporters viewpoint (who is also a user), it is strange that there is no difference between supported and unsupported versions.
On the other hand, I understand that not every requested feature can be implemented in the Redmine core (for different reasons, like maintainability), and if needed, these features can be provided by plugins or patches. But personally, I don't like these modifications with patches/plugins in production, because:
  • they can give problems during each redmine version migration, and than, you can lose a lot of time, certainly if you don't have any Ruby experience
  • the quality is in most cases not so good as the Redmine core (where everything is reviewed by an excellent team)

With my last point, I contradict myself, because your response was part of the review process, so I will shut up now.

(1-7/7)