[11.x] [policy] Require PHP 8.3 for Drupal 11

Just updated 📌 Track PHP 8.1 support in hosting and distributions Active with a graph from packagist showing Drupal 10 PHP installs. PHP 8.2 is at 17% of installs which is not too bad after three months.

Same screenshot for quick reference, and the live graph: https://packagist.org/packages/drupal/core/php-stats#10

Given Drupal 10 and PHP 8.2 were both released within a month or so of each other, whereas Drupal 11 will be released months after PHP 8.3, I think we can consider using PHP 8.2 adoption as a proxy for what PHP 8.3 adoption might look like. To me, 17% suggests an increasing number of new sites are going straight to PHP 8.2, but that Drupal 9-10 updates might stay on PHP 8.1 for longer - this would be backed up by the much lower percentage of Drupal 9 sites on PHP 8.2.

The other consideration here is that if we're able to do a longer LTS for Drupal 10, that gives more time for sites to update to Drupal 11, including to higher PHP versions.

However one thing that might not be the same between PHP 8.2 and 8.3 is distro support, since that often depends on the distros' own release cycles.

As I know all distros already moved to PHP 8.2 as default and there's one year for wide adoption

Meantime PHP 8.3 release managers are defined and Alphas will start at June 7 https://wiki.php.net/todo/php83

Updating title, tags and version number based on recent announcement at https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... →

Tagging for the distro support info.

I agree that, pragmatism for the distros permitting, we should probably set the minimum PHP to the absolute newest PHP version available (which will probably be 8.3), since D10 will be available for several years for applications stuck with older PHP versions.

Good timing, Debian bookworm was released three days ago and ships with PHP 8.2. Added to the issue summary.

Ubuntu doesn't have a release with PHP 8.2 yet, I assume it'll be the next-non-LTS release at the end of this year, then either PHP 8.2 or 8.3 in the spring LTS release 2024.

RHEL I did not check.

Update on https://packagist.org/packages/drupal/core/php-stats#10 - PHP 8.1 is around 80% of installs, and PHP 8.2 is around 20% 11 months after release.

I have not seen PHP 8.1 cited as a barrier for Drupal 9-10 upgrades, it is the long tail of contrib modules that people get stuck on rather than PHP versions. So I think we should go ahead and pick PHP 8.3 here.

- we're already compatible with PHP 8.3 in Drupal 10.2, this puts contrib in a good position to introduce compatibility if there are any issues. Most of the changes I noticed in core were quite internal things (like assert_options()) compared to some previous releases, so it might not even need changes for a lot of contrib code.

- it will have been out for 6-12 months by the time we release Drupal 11

- Drupal 10 will be supported at least until some time in 2026 which is coincidentally the year that PHP 8.3 will go out of security support, so for sites that stay on Drupal 10 for longer, getting onto PHP 8.3 prior to a Drupal 11 update will be recommended too.

I would like to set the minimum required PHP version for D11 to the newest PHP version available at the moment that D11 is released. We need to support D11 for at least 4 years. If for some reason you do not have an environment with a older/lower PHP version, than stay on D10. D10 will also be supported for at least 4 years. Let the developers that work on Drupal core/contrib work with all the newest that PHP has to offer. As such a developer I like to work with the newest stuff.

@daffie do you mean that if we end up using the December window you'd want the minimum to be PHP 8.4? If so I think we could open a postponed spin-off issue to discuss that once we've settled on a minimum version here.

Hopefully D11 will not have a December release. But if that happens, it should have a PHP 8.4 minimum version. AFAIK PHP 8.4 will be released in October/November 2024. Lets for now go for a earlier release than December. :)

Again if for some reason you have a hosting environment with older software you should stay on the previous major Drupal version (D10). D10 is still supported for another 2 years after the release of D11.

A new major version of Drupal should be released with all the latest stable versions for its dependencies. The same for the minimum required versions for its databases. For me as a developer on Drupal core/contrib I want to work with the newest software. I do not want to wait to 2 extra years until Drupal ups its minimum supported versions. With D10 we could have set the minimum required version for PostgreSQL to 15. PostgreSQL 15 was released on October 13, 2022. Drupal 10 was released on December 14, 2022. We did not do that. Only in PostgreSQL 15 was support added for native MERGE. Now I have to wait for D11, before I can use it in Drupal. That just does not make me happy. See: 📌 Improve support of native MERGE on postgresql 15 Active .

8.4 release schedule already defined https://wiki.php.net/todo/php84

Nov 21 2024 GA

But next year will should how Debian/RH&co will adopt 8.3

When considering "standard" PHP hostings (not container solutions), the PHP support here tends to be quite flexible. A lot of hosting providers tends to offer most recent PHP versions just after the these are released. But from my experience, it does not work this way with DB servers most of the time. These are often updated years after specific DB was released. So I personally do not think that it is a good idea to require for example the latest PostgreSQL released just few weeks before Drupal 11.

Even if we release in December I don't think we can realistically require PHP 8.4 as most distros will not have caught up. I think its fine to strike a balance between new features for developers while making life easier for end users by allowing them to use distro versions of PHP. Therefore to me PHP 8.3 seems a reasonable compromise as it should be fairly well supported by the time D11 is released. Anyone who can't upgrade at the time can stay on D10 on the extended support cycle as well.

I assume there's no news of PHP 9 yet, if it turned out that 8.4 will become 9.0 instead then I might be persuaded differently.

Another stats point: 60% of Drupal 9 installs are on PHP 8.1 and 5% are on PHP 8.2 (~20% are on PHP 7.4) according to https://packagist.org/packages/drupal/core/php-stats#9

Around 35% of 9.x installs were on PHP 8.1 when Drupal 10 was released, so that percentage has approximately doubled within the past year.

The timeline for PHP 8.1/Drupal 10 and PHP 8.3/Drupal 11 are identical (give or take the three release windows), so this is all a sign that the majority of sites are keeping up with PHP version requirements.

Interestingly on that graph you can see the percentage of Drupal 9 installs on PHP 7.4 slightly increasing in the past month, from 17% to 20% which we can probably assume is the sites that are furthest from a Drupal 10 update/most out of date including those on older Drupal 9 versions like 9.4, while others are updating to Drupal 10. Higher percentage of a smaller number in other words.

This is likely to be heavily skewed towards sites that under active development etc. since that means a lot more composer installs etc., but it's likely the trends can be relied upon even if there's not a direct installs to sites comparison.

Drupal 10 will be supported until at least June 2026 under the new major release policy, so it will be available with a lower PHP requirement for distros as long as dependencies allow. (Similarly, Drupal 11 will be supported until at least June 2028, etc.)

Going forward, 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.

Going forward, 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.

+1 This sounds to me as the best (most sensible) solution.

There might be serious challenge in PHP release cycle so PHP 8.0bwill get one more year of fixes

https://externals.io/message/121644

https://wiki.php.net/rfc/release_cycle_update

#24 is very good news, but for me doesn't change anything here.

Adjusting #14:

- Drupal 10 will be supported at least until some time in 2026 which is coincidentally the year that PHP 8.3 will go out of security support, so for sites that stay on Drupal 10 for longer, getting onto PHP 8.3 prior to a Drupal 11 update will be recommended too.

If the change in #24 happens, PHP 8.3 would be supported until the end of 2027, which means after Drupal 10 goes out of support, which lines up even better IMO - i.e. once you get your Drupal 10 site onto PHP 8.3, you can stay on PHP 8.3 until the very last minute, then update to Drupal 11, if you really want to.

Update the issue summary a bit to reflect latest discussion.

I think this needs review now.

Require PHP 8.3 for Drupal 11.

+1 for this proposal. I already mentioned that PHP support on shared hostings tends to be quite flexible, so even if sites are not running containers, this version should not make extra problems in 2024 (or 2025). And it will have a benefit for migration between D10 and D11 as well.

Also +1 for requiring 8.3 for 11.

Not sure I have the permission to RTBC but seems the consensus for php is 8.3 is fine.

+1, but with caveat that if we miss the June window it might need to be 8.4 assuming that's the next release

@larowlan if we go ahead with 🌱 [policy] Default to requiring the latest stable PHP release available when a new major version reaches beta Active then we'd always pick 'the PHP release available at the time of the first beta window' - so stick with PHP 8.3 even if we release in December 2024 just after PHP 8.4 comes out.

Thanks, following over there

This has pretty solid consensus amongst the release managers, so untagging.

+1 ... given that both me and @larowlan wear the framework manager hat going to remove the tag.

There are still a few todo's in the IS.

Also, the title would make me believe this ticket is actually changing the PHP requirements, but there is no patch or merge request to change this?

Added information for RHEL - there is no version offering anything above PHP 8.1, which unless the PHP rfc to extend the security cycle gets accepted beforehand and retrospectively applied, is going to be EOL in 11 months.

Debian trixie (unstable) still has PHP 8.2, but since bookworm, which was released in June 2023, included PHP 8.2, it seems likely that trixie will also update to PHP 8.3 before release. I don't have any special knowledge about this though, it's just a guess based on previous releases.

Adding 'policy' to the issue summary since we can open a separate implementation issue to actually bump the requirement once this is agreed.

Great! Title makes more sense now. Think the RTBC is justified now.

xjm point out that I had not commented on this issue. For the record I agree with the decision.

+1 for PHP 8.3

I think we're ready to go here.

I've opened 📌 [11.x] [PP-1] Add PHP 8.3 requirement to Drupal 11.0.x Postponed for implementation.

It might take a little bit of work to figure out how to document on d.o the PHP requirements for both 10.x and 11.x - we just switched over for 9/10 but with 10.x's longer support cycle we might not want to relegate it as quickly this time. So I I added a change record at https://www.drupal.org/node/3413288 → - not really very much to say, but at least it's some documentation until we complete the implementation issue.

Going to go ahead and mark this fixed, and we can sort out anything remaining on 📌 [11.x] [PP-1] Add PHP 8.3 requirement to Drupal 11.0.x Postponed . Thanks everyone!

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