Allow opt-in PHP 8.5 testing

There's following settings https://git.drupalcode.org/project/gitlab_templates/-/blob/main/includes...

  # The minimum supported version of PHP for the current stable version of Drupal.
  CORE_PHP_MIN: '8.3'

  # The maximum/latest supported version of PHP for the current stable version of Drupal.
  CORE_PHP_MAX: '8.4'

  # The next/prerelease version of PHP targeted for support by the current stable version of Drupal.
  CORE_PHP_NEXT: '8.4'

  # The minimum version of PHP targeted for support by the next Major release of Drupal.
  CORE_NEXT_PHP_MIN: '9.0'

  # The maximum/latest version of PHP targeted for support.
  CORE_NEXT_PHP_MAX: '9.0'

  # The next/prelease version of PHP targeted for support by the next Major release of Drupal.
  CORE_NEXT_PHP_NEXT: '9.0'

So after 11.2 the `CORE_PHP_NEXT` should be increased to 8.5

Wait till 11.2 release

I think we unpostpone this since 📌 Bump core versions to 11.2.3 and 10.5.2 Active is in.

I think it's a good time to allow start testing as all deprecations already commited and beta 1 is out

I’m away for a few days. Happy to review code but i won’t have time to actively work on it this week or next.

In 2 weeks next beta will arrive and probably core will have less issues (a lot of compatibility issues been fixed today)

If we want to encourage testing at PHP 8.5 via $CORE_PHP_NEXT then should we add a new variant, manually triggerable and off by default, which would run only when $CORE_PHP_NEXT is greater than $CORE_PHP_MAX? The jobs would not show up at all at the moment, because php max and next are both 8.4. This is similar to what we do for the 'max' php variant, it does not show up if $CORE_PHP_MAX is the same as $CORE_PHP_MIN. It would run PHPUnit I guess, and some of the linting jobs, maybe PHPStan? That all depends on if there is a new phpstan version for php 8.5

But in principle we need to decide if just changing the value of $CORE_PHP_NEXT is enough, and we document how to customize an exitsing variant, or show how to create a new one. I guess we need to work out if we don't make it easy then how many developers will do it. Happy to do the simple way if that is all that is required, but equally I'm happy to do the work to add a new full variant if that is what we want.

I’d go for the simple MR + document how to do it. I don’t think we need more variants as people can leverage existing ones (or even create new ones for their own projects).

I think we need to wait a bit for core's dependencies to be fixed as guzzle/kink produce too many warnings and contrib can't actually use it without patching like 📌 Discus adoption of #NoDiscard and PHP 8.5 Active

jeremy1606 → changed the visibility of the branch 3513062-core-php-next to hidden.

jeremy1606 → changed the visibility of the branch 3513062-core-php-next to active.