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

Parenting to Drupal 10 requirements.

I don't think we'll be able to drop support for PHP 8.1 on Drupal 10 during Drupal 10's lifetime. Assuming that's the version that will be in Ubuntu 22.04, it will be supported by them until 2027 (and if you consider their extended security maintenance, then until 2032). Drupal 8 still supports PHP 7.0, which went EOL almost 3 years ago, so even if we want to support Drupal 10 until 2027, that will be about parity with where Drupal 8 and PHP 7.0 are now. However, I also think we have the option of choosing to release Drupal 11 three years after Drupal 10 instead of four, which would be 2025, in which case we might want to EOL Drupal 10 at then end of 2026 rather than 2027.

For PHP 8.0, it's not in any of the major Linux distros, so I think we have more leeway with dropping it. The question is when.

This means raising Drupal::MINIMUM_PHP ... Existing sites running on the out of date PHP version will still be able to update

Do you mean MINIMUM_SUPPORTED_PHP? Because according to the docs of MINIMUM_PHP, that's a hard stop on existing sites running below that version, including the fact that we might be using the minimum PHP's new language features, or using dependencies that use those language features.

Back to the question of PHP 8.0, I think the whole point would be to raise MINIMUM_PHP and start using PHP 8.1's language features, like nested annotations, fibers, and other goodies. Our only prior experience with raising MINIMUM_PHP in a Drupal minor was when we raised it from PHP 5.5 to PHP 7.0 in Drupal 8.8. That was 1 year after PHP 5.6 went EOL (and also 1 year after PHP 7.0 went EOL so we treated PHP 5.6 and PHP 7.0 differently despite their same EOL date). If we were to apply the same pattern to PHP 8.0 that we applied to PHP 5.6 (and did not apply to PHP 7.0), that would mean raising MINIMUM_PHP from 8.0 to 8.1 in Drupal 10.5.

If we want to release Drupal 11 three years after Drupal 10, or in other words, at the same time as Drupal 10.6, then Drupal 10.5 would also be the last version in which we can add a new capability that deprecates an old one. For example, if we want to deprecate plugin annotations in favor of attributes, and if we need nested attributes to do so (which we might not if we refactor how we specify translatable plugin definition properties), then Drupal 10.5 would be the last Drupal 10 version in which we can do that. Though for the specific case of plugin annotations, given how widespread they are in contrib, we might want to set the deprecation deadline for that even sooner than Drupal 10.5, to give contrib maintainers more time to react to that. Since there might be other examples of things we want to deprecate but that require PHP 8.1 to do so, maybe we want to raise MINIMUM_PHP from 8.0 to 8.1 in Drupal 10.4, even though that would mean doing it sooner after the PHP EOL than we've ever done before.

If we think we want to actually raise MINIMUM_PHP from 8.0 to 8.1 in Drupal 10.5 (and certainly if we want to try to do it even sooner than that), I think we should communicate that no later than when we release Drupal 10.0. Ideally I think that for anyone installing or updating to Drupal 10.0 on PHP 8.0, we'd add a message during the install or update that Drupal 10.4 (or whichever other version we decide on) will be the last version to work on PHP 8.0.

According to https://packagist.org/packages/drupal/core/php-stats, 7% of Composer usage of drupal/core is still on PHP 7.2 (almost 1 year EOL) and 2% is still on PHP 7.1 (almost 2 years EOL), which is why I think that dropping PHP 8.0 in a Drupal minor, even in Drupal 10.4 or 10.5 will be at least a little bit disruptive to people.

If we think we want to actually raise MINIMUM_PHP from 8.0 to 8.1 in Drupal 10.5 (and certainly if we want to try to do it even sooner than that)

Here's another idea... PHP 8.0 EOLs on Nov. 26, 2023. Drupal 10.3 will be released the week after that. What if we therefore make 10.3 the version that raises the minimum to PHP 8.1, but we provide extended support for 10.2? Normally, 10.2 would EOL in June 2024, which is only 6 months after PHP 8.0's EOL, but what if we give 10.2 an extra year of security-only support, or in other words, EOL it in June 2025?

The upside of this (relative to not raising the minimum until 10.4 or later) is that it would allow core developers to start using PHP 8.1 features sooner, which would also mean being able to add PHP-8.1-requiring replacements to things that we want to deprecate with more lead time before Drupal 11's release.

A downside of this would be that contrib would have an additional Drupal minor to maintain compatibility with. For example, when Drupal 10.5 is released in Dec. 2024, contrib will potentially need to be compatible with 10.5, 10.4, and 10.2. However, contrib can use semantic versioning now, which means it could create a new minor for 10.4+ compatibility and still be able to commit security fixes to the last minor that's compatible with 10.2.

What if we therefore make 10.3 the version that raises the minimum to PHP 8.1, but we provide extended support for 10.2?

Sorry, just realized that that won't work, because 10.2 will be on Symfony 6.3, which will not be an LTS release, so we can't provide extended support on it. Therefore, I think the most sensible Drupal version to require PHP 8.1 is either 10.0 or 10.4. So if 10.0 is deemed to soon, then I recommend 10.4.

That means people on PHP 8.0 will be able to remain on 10.3 until Dec. 2024, 1 year after PHP 8.0's EOL, even if we don't offer any extended support for 10.3. But because 10.3 will be on Symfony 6.4, an LTS release, we could potentially decide to provide extended support for 10.3 if we think there will still be enough PHP 8.0 usage out there to warrant it.

Ideally I think that for anyone installing or updating to Drupal 10.0 on PHP 8.0, we'd add a message during the install or update that Drupal 10.4 (or whichever other version we decide on) will be the last version to work on PHP 8.0.

I still think we should do this, though s/10.4/10.3/.

Thank you all for the thoughtful discussion.

Regarding the options in the issue summary...

While I understand the clear advantages of option 1, I'm concerned it will cause enough pain and disruption to enough people that it may negatively affect Drupal adoption and retention.

If option 2 is pursued, I would like a strong warning in the status report of what version should be used.

Given #9 and #10, I suggested another option in #3196027-14: Contrib support solution needed for potential Symfony 4 to 6 upgrade, Symfony 5 only deprecations are not available in Symfony 4: to release Drupal 10.0 on PHP 8.0, 6 months later release Drupal 11.1 on PHP 8.1, and keep 10.0 supported for as long as we think is appropriate to support PHP 8.0.

I think the biggest downside with this suggestion would be managing perceptions (whoa, why go from D10 to D11 so fast!), but as I wrote in that comment, I don't think there'd be much or any added work for site owners to go from 10.0 to 11.1 as there would be for any minor upgrade: the major version number change would just be for the PHP and Symfony minimums, and site owners affected by those minimums could stay on 10.0 for a while if they want to.

To me, the problem here is that the Drupal community would like to wait with D11 for 4, 5 or even 6 years. I understand why this is great for site owners. Only for me this is the wrong thing to do. In D8 we "got of the island" and joined the PHP community. That same PHP community has chosen to do a 2 or 3 year major release cycle. Now we can put out our thumbs in our ears, stick our tongue out, wiggle out other fingers, make a funny face and say that we are doing 4, 5 or even a 6 year release cycle and that the rest of the PHP community is doing it wrong. Only then we are going to end up with problem like we have now with Guzzle version 6 and PHP 8.1. And also with the problem of this issue. To me the solution is simple, lets go with the rest of the PHP community and also do a 2 or 3 year release cycle.

Edit: The perfect time to release D11 would be for me, about 6 months after the release of Symfony 7 and with Symfony 7.

lets go with the rest of the PHP community and also do a 2 or 3 year release cycle

#4 suggests a 3 year cycle: D10 in mid-2022 and D11 in mid-2025. However, I think 2025 is too long to wait before we can start using PHP 8.1 language features, but #9 says that if we start D10 on PHP 8.0, then we can't start using PHP 8.1 language features until D11, but at the same time there are also concerns that a PHP 8.1 requirement for Drupal 10.0 would both negatively impact the adoption of Drupal 10 and leave some people stranded when Drupal 9 goes EOL.

The perfect time to release D11 would be for me, about 6 months after the release of Symfony 7 and with Symfony 7.

That would mean a 2 year cycle instead of a 3 year cycle. A 2 year cycle is what we had with Drupal 9, but I think it's too short. There's a lot of overhead that goes into a major version upgrade. For example, we generally don't allow any new features into the X.0 and X-1.LAST versions (e.g., into 10.0 and 9.4), so a 2 year cycle means that 25% of our minor versions are cut off from having new features. Also, per #3196027-16: Contrib support solution needed for potential Symfony 4 to 6 upgrade, Symfony 5 only deprecations are not available in Symfony 4, there's overhead on contrib, even when all that's needed is a 1 line fix or a fully automated patch, and that overhead on contrib translates into overhead on site owners as well. Although #3196027-14: Contrib support solution needed for potential Symfony 4 to 6 upgrade, Symfony 5 only deprecations are not available in Symfony 4 suggests an even shorter D10-D11 cycle, it does so in a way that reduces that overhead (e.g., it goes straight from 10.0 to 11.1, new features would be allowed into 11.1, and because the BC breaks between 10.0 and 11.1 would be known ahead of time, contrib could start with a ^10 || ^11 requirement to begin with).

I'm sad that we seem to be left with only bad options:

• Starting 10.0 on PHP 8.1 is a bad option for some people.
• Releasing Drupal 11 only 2 years after Drupal 10 is a bad option for some people.
• Not using PHP 8.1 language features until 2025 is a bad option for some people.
• Hard-breaking PHP 8.0 in the middle of the D10 cycle is a bad option for some people.
• The stepping stone approach I proposed in #3196027-14: Contrib support solution needed for potential Symfony 4 to 6 upgrade, Symfony 5 only deprecations are not available in Symfony 4 is a bad option for some people.

Thanks again for the discussion. I think @effulgentsia breaks this down well but throwing in my 2 cents that I also think most site owners and maintainers would prefer 3 years between major releases rather than 2. Although major releases are way way simpler these days, they still require more focus and attention than a minor release. Plus more new features can be added with an extra year which makes it more compelling to upgrade.

According to Dries: "Drupal is for ambitious digital experiences". Seeing there is a lot of great stuff in PHP 8.1 that we would like to use in D10. Makes waiting until D11 to use them not a recipe to create "ambitious digital experience". For me is setting the minimum required version of PHP 8.1 for D10 almost a must. For the sites where that will be a problem, lets give them more time. Instead of the now proposed 1 year before D9 will be EOL after the release of D10, lets extend it to 2 years before EOL. In that way we can release D10 with PHP 8.1 (which will make a lot of people happy) and give site owners more time to move to D10 (which also will make a lot of people happy). To me this is a better option then the ones that @catch listed in comment #13.

When we combine this with a new major release every 2 years, we do not have increase any of the requirements during the life of a major version. For the developers we have new major release 6 months after the release of a new major version of Symfony and the site owners have 2 years to migrate their sites to the new version. In that way the Drupal project has only to support 2 major versions at any time. The current one and the previous one. When D11 is released D9 will be EOL. Relative easy to maintain for the Drupal project. To me this is the most sensible solution.

Thanks @daffie. I like this reasoning. So, if I'm understanding correctly:

• Major release every 2 years
• EOL support increased from 1 to 2 years

This might be a good balance. :) But, since this is falling heavily on the shoulders of the release manager, core maintainers, security team, etc then it would be good to understand more of their thoughts on this.

I would say that if this were to become the "norm" that Dries should definitely cover this in a Driesnote to make it clear what the advantages of this timing would be. Having gone from many years between major releases to down to 2 years has been a big mind shift and "change is hard" as they say. :)

> Instead of the now proposed 1 year before D9 will be EOL after the release of D10, lets extend it to 2 years before EOL.

Unfortunately this isn't our decision to make. D9 runs on Symfony 4, and Symfony 4 is end of life in November 2023.

I opened #3238372: [policy] Decide on a 2 or 3 year major release cycle to discuss the release cycle options more.

If we go with option 2 in #3238372: [policy] Decide on a 2 or 3 year major release cycle, that would mean starting Drupal 10.0 on PHP 8.0, releasing Drupal 11 in 2024 and supporting Drupal 10 until November 2026, which would be 3 years past PHP 8.0's EOL, which will be the same situation that we're in now with PHP 7.0 and Drupal 8. What are the pain points that we've had with PHP 7.0 on Drupal 8 in the last year or two that would be worth us trying to do something different for PHP 8.0 towards the end of Drupal 10's life?

Then things get a bit better for Drupal 11+, because we'd get onto PHP 8.3 for Drupal 11 and support Drupal 11 until Nov. 2028, which would be only 2 years past PHP 8.3's EOL, which would be like where we are now with PHP 7.1 on Drupal 8, which as far as I know hasn't made things too difficult for us.

Retitling to differentiate this from #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4, which is a more narrowly scoped issue that needs to be addressed in the next couple months. This issue should be about our long-term / consistent practice for major versions that potentially have longer than the 3-ish years of security coverage that D9 gets.

I actually think we should go a step further and ship 10.0.0 with conditional logic that sets the values of RECOMMENDED_PHP (or a method replacement for it) based on the current date vs. PHP's known release schedule. That way we don't have to belatedly remember to do it each minor, and sites will still get the warning even if they're on an old minor. (Shipping warnings about updates in updates is always less effective than we want.)

Then all we have to remember to do is ship an override for the recommended PHP version if for some reason we aren't able to make Drupal compatible with it in time for the minor (or when PHP updates their release schedule, which will have much more advanced notice since it will happen at the beginning of the PHP version support rather than the end). Edit: It doesn't look like php.net provides API for this, which is unfortunate, but it still seems more reliable than the current approach to hardcode what they do document.

That becomes even more important if we do decide to deprecate or reduce support for the old PHP version during the major lifetime. Having conditional logic and referencing the PHP release schedule would give us a way to inform the user even of the exact dates when our recommendations and support will change.

Meanwhile, I posted #3261357: Increase Drupal 10's RECOMMENDED_PHP to 8.1 now. It's clear that we'd prefer people run PHP 8.1 for many reasons even if it's not feasible to require it. (I also think we could backport that to 9.4 since to my knowledge all the upstream and fatal errors related to PHP 8.1 are fixed, but we definitely know already it's the best choice for D10.)

In terms of what to do with MINIMUM_SUPPORTED_PHP, I can see the cases for both options, except for this bit:

Don't actually raise \Drupal::MINIMUM_SUPPORTED_PHP (or only do so with a longer grace period), however don't test or accept bug reports for older PHP versions.

Regardless of when or whether we increase MINIMUM_SUPPORTED_PHP, we should always test on MINIMUM_PHP and higher, even if we don't accept bug reports for it specifically. We manage to regress older PHP support at least once a month and only the fact that I subscribe to DrupalCI emails seems to get it fixed. If we don't test the old PHP versions, they will break. So I'd reframe this as:

Don't actually raise \Drupal::MINIMUM_SUPPORTED_PHP (or only do so with a longer grace period), but only accept bug reports for older PHP versions if the current HEAD test suite is actually failing.

(Not saying that's my preferred option, just that DrupalCI remains cheaper than human time if we go with that option.)

Going a bit further, here's what I would propose.

Just as a reminder for how each constant works:

1. MINIMUM_PHP: Drupal cannot be installed or updated below this version, at all. Corresponds to the minimum constraint we use for Composer.
2. MINIMUM_SUPPORTED_PHP: A warning is displayed below this version for update and (based on the current direction of #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4) installation that the PHP version is too old and might stop working in the future, but sites can still run and install Drupal updates.
3. RECOMMENDED_PHP: An informational message is displayed recommending this version "for best ongoing support", but there are no warnings, errors, or other disruptions when the value is increased.

Reiterating the expected PHP version release cycle:

• 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

I've included what we should have done in D9 minors to help illustrate the trend. Asterisks (*) are points where we didn't increase the requirement as much as we perhaps should have.

Ah, re:

sites will still get the warning even if they're on an old minor

The only issue with this is 10.0.x is unlikely to be ever compatible with PHP 8.2 (unless we release it in December), but it will be supported at the time PHP 8.2 comes out.

They'll also get a warning that they're on an out of date minor if this happens though... could be tricky though? But... maybe we just could pick the date that 10.0.x goes EOL to increase the recommended PHP version? Would mean recommending PHP 8.2 in mid-2023, about six months after it's released.

We could make the logic based on our own minor schedule with the assumption that we stick to June/Dec., since we have been successful nearly every time (except one I think) at supporting the latest PHP version in time for December. So, recommend PHP 8.2+ on the predicted 10.1.0 release date, recommend 8.3+ and support 8.1+ on the predicted 10.3.0 release date, etc. That way sites still see the appropriate messaging on whatever old version, but only after the Drupal release that is expected to be available to address the new recommendations.

In practice PHP seems to release the new PHP version on the last Thursday of November, and we release our minors on the second Wednesday of December, so there's only a 13-day gap.

Edit: We could also hardcode the recommended version as increasing on the June window, just in case, but then patch that back to the December window on all branches with coverage so long as we achieve fatal-free compatibility in time for December. And make MINIMUM_SUPPORTED_PHP increase specifically on the documented PHP EOL dates, and patch in the new EOL dates on all branches with coverage as soon as we learn them.

Adding my hypothetical proposed API in #3261447: Add an API for dynamically setting recommended and supported PHP versions based on known and predicted PHP release schedules.

In addition to the proposed API, we would still need to decide what to do for (1) Drupal's LTSes (like 10.4, 11.4), (2) situations where a dependency does break support for MINIMUM_PHP or above, (3) what bug reports we accept, etc.

I updated #3261606: Provide more specific messaging about the consequences of using an unsupported PHP version with the implementation details of what, specifically, would happen to 9.4.x if a dependency releases a version that is not compatible with Drupal 9's MINIMUM_PHP between now and its end of life.

I would apply the same policy to 10.x branches, along with more aggressive increases to RECOMMENDED_PHP and the proposal in #3261447: Add an API for dynamically setting recommended and supported PHP versions based on known and predicted PHP release schedules. In addition to the proposal there, if a dependency dropped support for MINIMUM_PHP during 10.x's active support, we would need to:

1. Rename update hooks in the development branch at the time.
    

2. Figure out what to do with that branch from a git perspective.

   E.g., say a dependency drops support for our MINIMUM_PHP while 10.3.x is in security-only mode, 10.4.x is the production branch, and 10.5.x is the development branch. The current 10.5.x would need to become 10.6.x (which is easy enough), but the new 10.5.x (branched after 10.4.5 or whatever) would need the old 10.5.x's name to work with Drupal.org integration.

   This would mean breaking folks' existing checkouts of 10.5.x, and I am not sure what exactly would happen to existing merge requests against the old 10.5.x.

Oh, we'd also need to figure out what to do if the new minor (10.5.x in the example) already had a tagged pre-release milestone (alpha, beta, or RC). I have no idea how we would handle that situation; maybe we just proceed with the minor release as per normal since it is within a month of the production minor (10.4.x in the example) going into security-only mode anyway.

Updated the IS with a more current proposal.

So given 10.x's minimum requirement of PHP 8.1, the earliest this is likely going to come into play is November 2024, when:

1. PHP 8.1 will reach its end-of-life
2. Drupal 10.2 will be approaching its EOL
3. Drupal 11 will either be in preparation or already released
4. Drupal 10.4 might be about to be released, or 10.3 might be the LTS, depending on #3 (and on other factors like jQuery 4 etc. that will affect D10's EOL).

The question implied by #33 is, would the latest minor of Drupal 10:

• (a) Do what we planned for Drupal 9 and increase both MINIMUM_PHP and the constraint for the dependency, or
• (b) Leave MINIMUM_PHP alone, and open up the constraint to allow both versions of the affected dependency? (This might not even be necessary; it could be a new major version of the dependency that drops PHP 8.1 support, but it could also happen in a minor or even a patch version. We've definitely lost support for PHP 5 in minor versions of dependencies previously.)

(a) has the advantage of being more explicit: If you are stuck on PHP 8.1, you still have security coverage from the previous Drupal minor for issues not related to the dependency, and there is no unexpected disruption mid-cycle for the new minor.

(b) has the advantage of being more flexible for the site owner, but could result in the site owner losing security coverage abruptly if they did not pay attention to the UI messages and the fine print of the PHP version support policy.

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.

I think the best we can hope for is to support currently-supported versions of PHP, and make best effort otherwise, but if our dependencies demand an upgrade, then there is not a lot we can do about it. If users are willing to stay on insecure/unsupported versions of PHP, there is nothing preventing them from also staying on insecure/unsupported versions of Drupal or other dependencies too.

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.