Add option to remove tagged releases from the version selector

I think this should be optional, probably an option for the whole site. (Not a per-project option.) I'm not sure if there is anyone out there using this in project module, but I don't want to take this out from under them. I do think we should keep this standard across all projects on Drupal.org.

For Drupal.org, we'll want to check the feasability:

• How many issues are filed against tagged releases?
• How many of those have a branch release to migrate to?

The issue version field is added by project_release, a submodule of project.

To do:
- The stats from #5. Do we move issues on tagged releases or make them less-findable?
- Show issue counts/warning on edit, so contrib projects know the trade-offs?
- Hide the new field if releases are not enabled for the project node.
- The actual functionality.

This should also speed up issue page loads for logged in users.

All open core issues for non-dev versions do have corresponding dev versions, so we would not be making any issues less accessible. We’ll need to draft a message for the auto update to move the tagged issues.

There are various closed issues that would be affected, but I don’t think they are important.

This should be okay to deploy as-is, since it is a configuration. For core, we’ll want to write a script to sweep up all the tag version issues into their dev versions.

The versions list on issue listing pages needs a followup, #2842544: Move ProjectIssueHandlerFilterSearchApiVersion into release/views/handlers. So even if this is enabled right away for core, issues still filed under the tagged versions will still be accessible. If people update those issues, only the remaining options will be available.

Deployed on Drupal.org and configured this project to use it:

Tagged releases in unchecked in the last form element.

I guess this train already left the station, but I'm not necessarily a huge fan of this change. Part of the point of having official releases is to make it easier to reproduce bugs, since everyone can know what version of the code is showing the problem. Yes, feature requests should always be tied to a branch, not a release. However, I think there's still value in bug reports being reported against a specific version, not just a branch.

Also, point #3 from the summary is what the "meta version" options were supposed to help solve. People shouldn't be searching for issues via 8.x-1.x-dev, they should be using "8.x issues". The meta version options are already at the top of the list when filtering/searching for issues.

That said, I can see that having dozens of stable releases on each branch makes the version selector unwieldy.

If everyone thinks this is an improvement, maybe we could at least update the issue summary template to encourage people to include information about the specific version of the code they're using when reporting bugs?

Thanks,
-Derek

It is optional, so for projects where maintainers especially need this information, it can remain checked.

This is definitely going to make it easier to file and find core issues. Thanks @drumm!

@drumm, I tested this for core, and it looks like issues that were filed against a version (some 17k) will be moved to 9.x by default as soon as someone updates them. I don't think we want that. So probably we should do the bulk update, at least for open issues. Disabling again for now until we can do that.

Should we file a separate issue for migrating open core issues to their branch?

Yes, since that's not something for project module. Either drupal or infrastructure project. Like the core minor version updates, main thing I need is a second draft of “Core issues are now filed against dev versions.” for the comment to go with the bulk version update.

#2847734: Bulk update core issues from tagged releases to dev versions is the followup issue.