Increase CORE_PHP_MAX to 8.3

Did PHP_MAX get increased to 8.3 when CORE_STABLE moved from 10.1 to 10.2? Had a look but I can't find the history.

However, when the check-versions job alerts us to a new stable version would it be possible to check what php version that is associated with? The php version would not be updated without the Core stable version also being changed, so it would make sense to do them in the same process. If it can't be automated then at least an echo/reminder to check manually?

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal.ph...

- Drupal::MINIMUM_PHP
- Drupal::RECOMMENDED_PHP

Good questions. So maybe 8.2 is good after all. We still have CORE_PHP_NEXT if wanting to try 8.3.

Maybe we can have the scripts check those values against the values set in in the Drupal.php file.

PHP 8.3 is supported by Drupal 10.2 and people are reporting bugs with it for contrib modules. I think it makes sense that PHP_MAX is what it says in the name, the MAX/most recent supported PHP version for a given core version?

Yeah.

I see that 8.3 is supported by 10.2 here: https://www.drupal.org/docs/getting-started/system-requirements/php-requ... →
I got confused with the code in core.

Changing to 8.3 is real quick. I'll put that MR together now.

@jonathan1055 - we can defo check Drupal::MINIMUM_PHP in the "check_versions" job, but not sure about the MAX or NEXT values as that'll depend on other factors which might not be able to be scripted.

The part of updating the value to 8.3 is really "Needs review".

We could commit that part and continue on this issue for the job to check the minimum version, or just mark it as "Needs work" until we have both (the script part shouldn't be too complex).

Yes let's get this merged, then continue with changes to the script. RTBC.

Ok, merged, and back to "Needs work" for the extra checks.

I'm grooming issues in the queue. I think that if we want extra checks to be made in check-versions, these can go as follow-ups.

OK. I have reverted the title, otherwise it looks like the second change was also done here.

Automatically closed - issue fixed for 2 weeks with no activity.