Lower PHP requirement from 8.3 to 8.2 in Drupal 11 due to increased security support

😉

I don't think we are using any PHP 8.3 features yet, but we should be able to find out easily by adding an MR with 8.2 gitlab pipelines added back (which is all we'd need here apart from changing some constants down to PHP 8.2).

I think we also need to do a change to the change record then?

https://www.drupal.org/node/3413288 →

Or I guess this would require a new CR? 🙂 Not sure about the process here.

If we lower this, should we close this as won't fix 🌱 [policy] Default to requiring the latest stable PHP release available when a new major version reaches beta Active ?

We should set the minimum PHP requirement to the highest stable PHP version available at the time beta1 of the major is released. That means PHP 8.3 for D11.

@BramDriesen: I think this issue is only possible and the change record would only happen once the PHP team announces the final decision. So we are preparing the code changes required here and then going into hold to see what the PHP team decides at the end (but it looks super likely that it will be going ahead with the one year extension).

How do we get around this composer fail in the pipeline which is I think due to the remote package requiring a higher version?

Your lock file does not contain a compatible set of packages. Please run composer update.
  Problem 1
    - drupal/core is locked to version 11.x-dev and an update of this package was not requested.
    - drupal/core 11.x-dev requires php >=8.3.0 -> your php version (8.2.0; overridden via config.platform, actual: 8.3.4) does not satisfy that requirement.

@Gabor I was going to say we might need to update more composer.json files like

core/lib/Drupal/Component/Plugin/composer.json 

but that still only requires PHP 8.1, so I think we forgot those in the first place..

We might need to lower the requirement first, and only then add back the gitlab ci configuration for PHP 8.2? Or commit this and hope it resolves itself after commit, but be prepared to rollback if not?

With the performance improvements reported for 8.3 I would be inclined to leave this as is and give ourselves the longest runway

@larowlan: Drupal core already has an automated system to drop support for PHP versions that go unsupported. Symfony 7.4 goes to the end of 2029 (https://symfony.com/releases/7.4) while even with an extended PHP 8.3 support, that would only go near the end of 2027.

I am hopeful the performance improvements will lead to faster adoption of PHP 8.3. Do the performance improvements require new language constructs though? Lowering the requirement to 8.2 would not mean people can't use PHP 8.3 :)

Here are some performance benchmarks from Kinsta: https://kinsta.com/blog/php-benchmarks/#drupal . It seems like that for D10 / Symfony, there are big peformance improvements with PHP 8.3 (in comparision with PHP 8.2). It does not say anything about using new PHP constructs, as it seems like they were using just a clean Drupal install, without any changes. On the other hand, yeah, we do not prevent using higher supported PHP version. That said, I personally lean more towards keeping PHP 8.3 as a minimum PHP version (mainly because PHP 8.2 will be security-fixes-only from Dec 2024, so still a bit "outdated" for me).

📌 Fix remaining methods with #[\ReturnTypeWillChange] attribute RTBC introduced PHP 8.3 only syntax (usage of true as return typehint)

Re #7 if we go ahead here, I think we should re-purpose 🌱 [policy] Default to requiring the latest stable PHP release available when a new major version reaches beta Active . It'd be good to have documented default for each major that doesn't change unless we explicitly want it to, rather than having to work it out from scratch every time.

#14 makes this more complicated than just adding back the gitlab environments and changing some constants. If that's the only example it wouldn't take much to change it to bool instead of true though so we could still go ahead here if we want to.

fwiw I think the extra year of support does mean we should look at this properly again. Added an extra note on 🌱 [policy] Default to requiring the latest stable PHP release available when a new major version reaches beta Active .

Discussed further with @longwave, @Gábor Hojtsy, and @catch; we agreed that since we are already using PHP 8.3 syntax, it doesn't make sense to go backward.

My preference remains to always use the highest PHP version available, because it's not only about what versions PHP supports; it's also about what versions of PHP our dependencies support (not just Symfony). With a two-year major release cadence and maintenance minors for majors after their two-year mark, there's no reason for the new version not to be as forward-compatible as possible.

xjm → credited longwave → .

Can't recall what the current status is for crediting wontfixed issues discussed in good faith, but saving them for posterity just in case.