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

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.