Contrib.social

[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, over 3 years ago
Updated 14 April 2023, over 1 year 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

  1. 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".

  2. 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).

  3. 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.

  4. 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
Base  →

Last updated about 3 hours ago

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).

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 1 year 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 1 year 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.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024