[policy, no patch] Process for dealing with EOL PHP versions during the Drupal 10 and future release cycles

Open on Drupal.org →

Created on 13 July 2021, about 4 years ago

Updated 12 April 2023, over 2 years ago

Problem/Motivation

Closely related to #3173787: [policy] Require PHP 8.1 for Drupal 10.0 if a dependency does, otherwise require PHP 8.0. (up from 7.3 in Drupal 9) → and 📌 Track PHP 8.1 support in hosting and distributions Active but deserves its own issue for Drupal 10.

Drupal 10 is due to be released in mid-late 2022, and may run on Symfony 6.

Symfony 6 is due to be supported until November 2027, and will require PHP 8.0.

We have numerous other PHP dependencies of Drupal core, which may increase their PHP version between 2022 and 2027, during Drupal 8 and 9 the first dependency to raise requirements has usually been phpunit.

Additionally, PHP itself has three year release cycles:

PHP 8.0, 2020-2023
PHP 8.1, 2021-2024
PHP 8.2, 2022-2025
PHP 8.3, 2023-2026
PHP 8.4, 2024-2027

As you can see from the list, PHP 8.4 is likely to be the lowest supported PHP version when Drupal 10 itself goes EOL.

Proposed resolution

Starting with Drupal 9.4, sites will automatically receive warnings that there PHP version is "too old" when it is EOL according to PHP → . The consequences of a PHP version being "too old" → are documented on the PHP requirements handbook page, which essentially boils down to "your site might lose support if a dependency drops support for your PHP version".
In November of each year, we will add the end-of-life date for the recently released version to the above API, and backport that change to the bugfix branch (since it is not disruptive until the version is actually end of life, which will be three years in the future).
Each year, we will begin to make core compatible with the new PHP version as soon as an alpha release of it is available. We will increase RECOMMENDED_PHP to the new version once there are no longer any critical core compatibility issues with it, in the December release if it's possible, or in the following June release if it's not.
The issue summary of #3261606: Provide more specific messaging about the consequences of using an unsupported PHP version → outlines in some detail the specific steps we would take should a dependency drop support for PHP 7.3 or 7.4 prior to Drupal 9's end of life (essentially releasing an off-schedule minor that increases constraints to the dependency's required PHP version and the version of the dependency that has the new requirement, and then marking old minors as no longer supported if a security release happens for that dependency).

For Drupal 10, this would be more disruptive since we are talking about branches potentially in the middle of the series rather than at its end, but we could theoretically widen constraints in the upcoming minor and potentially release it earlier than scheduled.

Remaining tasks

Release notes snippet

TBD.

🌱 Plan

Status

Active

Version

10.0 ✨

Component

Last updated about 3 hours ago

Maintained by
🇺🇸United States @effulgentsia
🇬🇧United Kingdom @catch
🇬🇧United Kingdom @alexpott
🇦🇺Australia @larowlan
🇺🇸United States @bnjmnm
🇫🇷France @nod_
🇪🇸Spain @ckrina
🇬🇧United Kingdom @justafish

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.

Needs release manager review
It is used to alert the release manager core committer(s) that an issue significantly affects the overall technical debt or release timeline of Drupal, and their signoff is needed. See the governance policy draft for more information.

Needs product manager review
It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

Drupal 10 beta should-have

Incomplete comments

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment over 2 years ago →
🇬🇧United Kingdom longwave UK
Agree with #33 and #37; I don't believe we can decide a policy now that will apply to all future versions, because it depends on multiple factors: the dependency itself, what choices they make, and what the break is - if for example PHP decide to release 9.0 instead of 8.3 or 8.4 then we have a bunch of very different considerations to make, all depending on what our dependencies themselves do about that.
Comment over 2 years ago →
🇳🇿New Zealand quietone
In terms of policy, I think longwave is on the right track that whatever we implement it is a best effort. But, we can state what our aim/considerations are when making decisions. Such as keeping site owners informed and finding flexible solutions etc.
Comment 26 days ago →
🇬🇧United Kingdom catch
PHP's support cycle changed since we last discussed this, and there's now four years of security support for each release.

https://www.php.net/supported-versions

This means Drupal 10's minimum of PHP 8.1 is supported until December 2025, while we're intending to support Drupal 10 until December 2026.

Drupal 11's minimum of PHP 8.3 is supported until December 2027 etc.

I think the main consideration here is which PHP version we start a major release on, e.g. 🌱 [11.x] [policy] Require PHP 8.3 for Drupal 11 RTBC , so I'm going to postpone this issue on 🌱 [policy] Default to requiring the latest stable PHP release available when a new major version reaches beta Active .
Comment 26 days ago →
🇬🇧United Kingdom catch

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024