Bulk update core issues from tagged releases to dev versions

Yay, looks good to me! (OTOH https://www.drupal.org/issue-queue/how-to#Version will need updating for the way it talks about features not going into stable versions, which is not true for Drupal 8 anymore, but that has nothing to do with this issue :)

The linked document lacks a lot of info that is in https://www.drupal.org/core/d8-allowed-changes on what branch should be used; do we want to link that instead for D8 issues?

IMHO we should cross-link from the docs page anyway? Or do you mean we should have a different comment posted to Drupal 7 and 8 issues? (Issues for prior versions have been marked as outdated already).

Yeah, that version documentation for features looks out of date (for Drupal 7 too - I think it probably dates back to Drupal 5 or 6). I suggest rewriting it as follows, using somewhat similar text as the "Choosing a version for a bug" section above it:

Choosing a version for a feature request

When making a feature request, always choose one of the development versions (-dev). To best help developers, test the latest development version to see if the feature needs to be added there and file an issue against that version if it does. Maintainers will often want to add the feature to the newest version first before potentially backporting it to older versions (for example, this is the policy used by Drupal core).

I think that covers enough information without mentioning anything D7/D8 specific. (But perhaps the situation for choosing a version for bugs is more complicated and needs a rewrite too.)

If you want to add links to https://www.drupal.org/core/d8-allowed-changes or https://www.drupal.org/core/backport-policy, I would recommend adding them to the page at https://www.drupal.org/node/10262 since that is the page that is already linked to higher up on the issue queue page (in the "Choosing a category" section) via the following text:

Feature Requests are for situations where the software works as designed, but the design can be improved. Before making a feature request for Drupal core, please read Criteria for evaluating proposed changes.

And it's also the page that's linked from the green help text when you go to create a core feature request:

If you are submitting a feature request, please review the criteria for evaluating proposed changes.

#2631820-44: [policy, then infra] Bulk update core issues for relevant minor versions has the script that can be adapted to do this.

Will you adapt it so that it runs on closed issues also, though?

There are a lot of issues in the closed state that are filed against a specific (non-dev) core version. On the one hand, most of those issues aren't likely to ever be commented on again. However, people sometimes do leave comments on closed issues, and if they do that without the version being auto-updated it will mess up the version after their comment is saved.

Agreed that this should run on closed issues that are on the wrong version.

Bump? ;) Are we still planning to do this? What exactly "needs review" in here? The text of the auto-generated comment? Anything else?

I guess we need a coordinated moment to reconfigure the core project to stop allowing tagged releases, do the bulk update, and update (all) the relevant docs. Is scheduling that window what's blocking this? Do we want to flesh out all the proposed doc updates in here?

Can someone who understands the status update the summary to enumerate next steps and how to move this along?

Thanks!
-Derek

OK sorry, took me more than a reasonable amount of time to understand that this was a separate issue and #99970: Page cache matching is case insensitive was the test issue. I did a bit more work on the issue version info. For the text, I'd propose:

Core issues are now filed against the dev versions where changes will be made. Document the specific release you are using in your issue comment. <a href="https://www.drupal.org/issue-queue/how-to#Version">More information about choosing a version</a>.

Thoughts?