[policy] Default to requiring the latest stable PHP release available when a new major version reaches beta

Plus one for this

I support this change.

I have added the text to be included in documentation. Right now, that is likely to be a new page about the release process that is intended for developers.

Interesting, this links to https://wiki.php.net/rfc/release_cycle_update but that says it has a date of 2024-03-21. May be the date for the 2.0 version.

Based on packagist data on PHP version usage, PHP 8.3 adoption was only 6.4% in January: https://stitcher.io/blog/php-version-stats-january-2024. While PHP 8.3 shot off much faster than 8.2 did, it still lags behind the speed of adoption of PHP 8.1 and that took more than a year to get to roughly 35% of adoption.

I think we have our own struggles with getting people on new major versions, making it this much harder by requiring the bleeding edge version for a couple minor (feature) releases when there is no more features on the older major sounds quite ambitious.

Am I reading the data wrong? I actually proposed 📌 Lower PHP requirement from 8.3 to 8.2 in Drupal 11 due to increased security support Closed: won't fix .

I think the main group of sites that would benefit from lowering the requirement to PHP 8.2 are those sites that are already on PHP 8.2, because that completely decouples updating PHP and Drupal version for them.

Sites that are on PHP 8.1 will still need to update PHP version to get onto Drupal 11, so if they have to go from 8.1 to 8.2 or 8.3, it's not going to make a huge difference probably.

If we take this as 30% per https://stitcher.io/blog/php-version-stats-january-2024 that is quite a lot of sites, and comparing it to the PHP 8.1 stats, it could still be 30% at the end of the year (not the same sites/hosts, but because some people will update from PHP 8.1 to 8.2 to replace the hosts updating from PHP 8.2 to 8.3). Obviously these numbers don't correlate to Drupal installs, but since we don't have Drupal-specific data, it's probably the best we can do.

My personal view is that an extra year of security support for PHP insulates us a bit more against #2 in the issue summary. I think #1 is about the same either way - i.e. sites can and should get onto PHP 8.3 on their Drupal 10 codebase, then go to Drupal 11.

As per 📌 Lower PHP requirement from 8.3 to 8.2 in Drupal 11 due to increased security support Closed: won't fix , we will continue to require PHP 8.3 for Drupal 11 since we've already adopted PHP 8.3 syntaxes in some places.

Per @catch, we can reconsider what we want to do for Drupal 12.

My preference however remains that the latest Drupal version always be as forward-compatible as possible, since the previous Drupal version will be available for about two years with support for older PHP versions. This helps us when dependencies release new minor or major versions that are only compatible with newer PHP versions.

Conversely, if one of our dependencies wasn't sufficiently compatible with the PHP version by a time when no other blockers remained to a major release beta, I'd go with the older version for that major only.

Updated the proposed text with a more complete suggestion, taking into account #7

I also don't really see any real big problems here. Most hosting providers I've come across are quick to adopt newer PHP versions. Maybe the slower ones to adapt are the shared FTP "kind" of hosting, long time since I've used one of those so can't tell for sure.

Nice to see the boost in performance as well! Quite a big difference there.

Update:

https://stitcher.io/blog/php-version-stats-january-2025 has PHP 8.3 at 32.7%

This compares to 5.1% for PHP 8.4, 28.6% for PHP 8.2, and 18.1% for PHP 8.1

It was 19.9% in July 2024, which is more or less half-way between January 2024 and January 2025 numbers, nothing exciting just shows it's steady over the year rather than a recent jump or anything.

Looks like PHP 8.2 usage peaked at 32.3% and has started to go down slowly since. No PHP version is reaching over 35% usage at any one time because there's always lag from older versions and then a new release.

I definitely don't think that PHP version is what stops existing sites from updating - most of them will be waiting for contrib modules to be compatible until around now relative to Drupal 11.0.0's release, and then things will start to pick up over the next six months, based on previous release cycles, but with less pressure to update due to Drupal 10's longer EOL.

Also don't think we have any evidence that new installs are prevented from using Drupal 11 due to the PHP version. If our earliest release date is half way through the year, then based on packagist, the version is already on 18% usage by that point, which considering inertia for existing sites to update seems not bad?

In practice what this would mean is that Drupal 12, released at the earliest June 2026, would require PHP 8.5, which will be released November 2025.

https://github.com/php/php-src/issues/17959 is a good specific reason to require PHP 8.5, because it will allow us to remove the massive and incomplete attributes workaround in 📌 Add a fallback classloader that can handle missing traits Active .