Although most developers want to know about defects against any software, no matter how old, not all companies want to automate this. Some companies see bugs in old software as an opportunity to talk or meet (actual people!) with old customers, to try to get them to upgrade to a currently supported version.

Scenario:
1. A really old release (say two major versions old) is deemed obsolete and no longer supported.
2A. Company adds a comment to the release node saying "please consider upgrading"
2B. Company immediately disables comments for the release node.
3A. Customer tries to log a bug against that ancient release.
3B. Issue tracer checks status of release, finds it does not allow comments, and refuses to allow a new issue, and optionally redirects customer to a page promoting the latest release (or the project node).

Obviously this is not everyone's cup of tea. It WOuld have to be an optional setting for each project, like "redirect issues if comments are disabled".

Just a thought, not a big deal.

Carlos

Comments

aclight’s picture

aclight commented

To be honest, this seems like a pretty obscure use case to me.

My guess is that many/most sites running project* disable comments on project release nodes, and either way the connection between disabling comments on a release node and that meaning that issues should not be created against that version is kind of abstract, in my opinion.

Another problem with the workflow you've proposed is that you suggest that when a customer "tries" to log a bug against an old release that the user be redirected to a different page. However, unless we just used javascript to redirect the user when he selects an old version from the drop down list on the project issue add form, the user would have first filled out all of the information about the bug, then submit, then is told that there bug won't be accepted. That would certainly annoy me, as a user. If you do it through javascript then people with js disabled will still have this problem.

Furthermore, I don't really think a feature like this belongs in project*, since as I said I feel like this is a use case that not many will need, and I think we'd prefer to not complicate project* more than it is already.

I can't think of any reason why you couldn't write your own module that would provide this functionality for your site. As I said earlier I'm not sure you could get this to work like you really want it to at least in the case where js is disabled, but having the code in project* wouldn't help with that.

I can see some utility in having the option to disable issues against certain releases, but I definitely don't think whether or not the release node in question allows comments is the way to indicate that a release shouldn't be in the select box for version. I'll keep this open for now in case anyone else wants to chime in and tell me that they'd love to have this feature, but I'd lean toward won't fix on this.

aclight’s picture

aclight commented
Status: Active » Closed (duplicate)

Actually, it turns out this is a duplicate of #97568: allow maintainers to restrict choices for "Version" in new issues/replies.