Disable previous major testing with D9 so that modules can prepare for D11.0

Testing previous major (Drupal 9) is disabled by default. When Drupal 11.0.0 is out (end of July as per https://www.drupal.org/about/core/policies/core-release-cycles/schedule#... → ), we will update the previous major to be the latest Drupal 10 stable version, but I don't think that we should do it before that.

So you could have for now OPT_IN_TEST_NEXT_MAJOR: 1, and then once we do the above swap, change it to OPT_IN_TEST_PREVIOUS_MAJOR: 1. That way you'll get Drupal 10 and 11 before and after.

If your concern is rolling the change to a big list of modules, you could leverage the "remote" includes from GitLab CI. You could have a centralized variables file for all your modules somewhere accessible and then change all your modules to read from that variable or file.

include:
  - project: $_GITLAB_TEMPLATES_REPO
    ref: $_GITLAB_TEMPLATES_REF
    file:
      - "/includes/include.drupalci.main.yml"
      - "/includes/include.drupalci.variables.yml"
      - "/includes/include.drupalci.workflows.yml"
  - 'https://raw.githubusercontent.com/Berdir/drupal-modules/main/gitlab-ci-variables.yml'

In this scenario, once the switch happen, you'd do the change in one file and it will be pushed to all. Also, I mentioned "variables" here, but you could centrally override any part that you want with this approach really.

> So you could have for now OPT_IN_TEST_NEXT_MAJOR: 1, and then once we do the above swap, change it to OPT_IN_TEST_PREVIOUS_MAJOR: 1. That way you'll get Drupal 10 and 11 before and after.

Yes, that's exactly what I'm trying to avoid, having to do that.

The remote include is an interesting workaround, it does feel weird to have that configuration outside of the repository and even outside of drupal.org. It also means nobody but me is able to make a change to that. Sure, they can still override it either directly in the file or or point to a different locations, but then it's theirs.

I honestly don't understand the reluctance to stop D9 testing (again, I'm not suggesting to switch to D10, just switching to disabling it, you will soon need the ability to not have next major or previous minor testing anyway). For Drupal CI you (DA/DrupalCI maintainers) were pretty quick to force disable all Drupal 8 and 9 testing configurations when they were no longer supported. But that's your call I guess.

and even outside of drupal.org...

It can still be inside drupal.org as another project.

reluctance to stop D9 testing

We basically want to offer a flexible solution, and not put blockers on what's possible, and then leave maintainers decide what's best for their modules. There is nothing stopping them even testing Drupal 8 or even using any other testing tool (ie: cypress). The PREVIOUS_MAJOR is disabled by default, so anybody enabling that will really want or need to test for Drupal 9 in this case.

Obviously, our efforts will go into current and future versions of Drupal, but sometimes low hanging fruit (like offering previous major itself) is easy and useful for many people that need to maintain. If we see people abusing this or the costs go crazy, we can take action, but that's not the case so far.