[9.4.x only] Drop official PHP 7.3 support in Drupal 9.4

I am in favor of option 1 so as to be absolutely clear.

Is it just Ubuntu LTS that's holding things up? What about other LTS distros?

I think we can be more aggressive, and we should stop supporting php7.x as soon as the regular support for it stops, if I understand it correctly - that means we're supporting each minor version for 3 years (2 of regular support + 1 of security only support)? Can we decrease that to just the regular support?

This would mean that we never allow installs on a version that's not supported by php. In the current option 1, we're allowing installs on non-supported php versions for up to 5 months, in this proposal we're "forcing" upgrades for maximum 7 months before security support drops.

Disadvantages:
- prevents using Ubuntu LTS releases that still backport security fixes to the older version.

Assuming option 1, I'm wondering whether it would be acceptable for organizations on LTS releases (Ubuntu or else) to use the latest Drupal 8 minor supporting the PHP version their distribution of choice ships with, and backport D8 security patches. Considering there are also paid services out there that could help with backporting and publishing such patches. Of course they would be "frozen" on that minor, but this would be consistent with the choice of adopting a linux LTS release.

The problem with LTS' is their longevity. In the scenario you give it's not inconceivable that they'd be on 8.5 and trying to apply patches written for 8.9 to it. The further apart those version numbers are the more likely the patch simply will not apply.

Also, I would imagine that some Drupal security releases update 3rd party libraries to fix an issue rather than try to maintain our own patch fork. In these cases there'd be no Drupal patch, just a composer change. Upgrading a library with composer has the potential to break a lot of stuff.

We aren't the only project with this problem. I don't know of a good solution either.

[This may rambling, but I have the window open and keep coming back to this periodically].

This is a tough one. I think the biggest challenge is the LTS thing for server-grade OS (Ubuntu, CentOS, RHEL, etc).

What we can't lose sight of is that not everyone is using containerized deployment, or even CI/CD. So, swapping PHP version isn't an easy as changing the base container in the Dockerfile.

These users probable represent the extreme ends of the spectrum, self-hosted sites (by this I mean shared hosting and some of the traditional commodity VPS hosting) and corporate sites in their own infrastructure.

I think we also need to keep in mind that we underestimate the number of people who ready CRs. The Symfony 3 and jQuery 3 changes caught a lot of people off-guard.

I think we need to gather information on probable PHP versions in LTS versions and chart out like #2842431-64: [policy] Remove PHP 5.5, 5.6 support in Drupal 8.7, but with additional info about LTS windows.

My gut tells me there is an option three here, which is to bump PHP version to reflect an N-1 strategy of what is in LTS, and potentially time alphas or betas to coincide with LTS release dates.

The only solution I can see is to pick a version of Drupal for LTS and extend it's support. That increases our workload, and it isn't the kind of coding that people will flock to do either.

Would it be useful to only upgrade to higher minimum versions of php for major releases such as a 9.0?

That gives users a predictable path - the platform will keep working until the next major release.

Otherwise there will be users who wont be able to upgrade past an arbitrary release where the requirements (and potentially code) have changed to no longer make their installation supported - all without the warnings that eg Drupal 6 was given.

EDIT - I have put a similar comment in the other issue. Not sure which is the best one for it. I think the versioning needs to be considered.

nbz: That is essentially the status quo. The challenge is that Drupal 8 is likely to last as long as Drupal 7 (6 years and counting), and PHP is moving a lot faster than it used to. That means within Drupal 8's expected lifespan and likely before we even are seriously talking about Drupal 9,co even *finding* a developer with PHP 5.5 to test things on will be a challenge. Meanwhile, there's a host of new language features that we're unable to use for a half-decade after they're released, and dependent libraries we use may move on to later PHP versions without us. (This is already happening.)

The longer Drupal lifecycle and shorter PHP lifecycle means the status quo is no longer viable. The question is what is going to be more viable.

Much as I like new language versions, I don't think it's practical to drop a version before its Security EOL. That just becomes too aggressive for the "dump in a corner and forget" self-hosters. For people on professional hosts (like Platform.sh, disclaimer, I work there) switching PHP versions is super easy and a non-event, baring any issues with code compatibility (which we should be resolving as we go anyway). That's unfortunately not the whole market yet.

Another factor: Modules can declare a higher PHP version than core. I have no idea what the percentage is that do, but that may be something else to monitor or check to see how aggressive it's safe to be.

Disable automated testing etc., but don't actually increase the requirement in code (except possibly to show a hook_requirements() warning if we add that). This will allow people running older PHP versions to keep doing so, but we won't accept bug reports etc. for anything specific to that version.

Feels dishonest. Either we support something or we don't.

If we take this into account:
> PHP 7.0 has security support until 3 Dec 2018
> PHP 7.1 has security support until 1 Dec 2019
This means that PHP 7.0 is discontinued 8 months after the release of Ubuntu 18.04 (which will ship with 7.2), and 7.1 is discontinued a year and a half after the release of Ubuntu 18.04.
Both sound reasonable, especially since our releases usually happen in early April, which gives us an additional grace period.
If we take April as the official compat-drop time, that gives us:
- April 2019 for the 7.0 drop, which is a full year after the 18.04 release
- April 2020 for the 7.1 drop, just in time for the 20.04 release.

(I am basing my argument on Ubuntu cause they're the most sensible right now, the RHEL/CentOS policy will never make sense for us).

Since the initial discussion we also determined the release date for D9 (june 2020, with december 2020 as a fallback).
Since that is a year after the PHP5 drop, we could re-evaluate the minimum PHP version for D9, and leave D8 alone.
For that it would make sense to at least make PHP 7.2 the new minimum.

The concern for us for not dropping support for PHP 7.0 and 7.1 is that Drupal 8.9 will need to have a 1.5 year lifetime, and by its EOL even PHP 7.3 will be reaching the end of its support. This means our dependencies could well create security releases that require newer PHP versions, and the result for site owners would be a break during a security window instead of in advance of a minor.

catch and I discussed treating PHP 7.0 and 7.1 the same way we treat PHP 5.6 in 8.7, with a warning on upgrade, but standardizing practices around it going forward.

I think now is a good time to start gathering data on the % usage of PHP 7.0, hosting support for PHP 7.2/7.3, etc.

This is a soft-blocker for opening 9.x (we should announce the policy a good year ahead of the release, and that's coming up quickly now). And it (or a child of it) is probably a hard blocker for #3007300: [META] Release Drupal 9 on June 3 2020, so parenting accordingly.

#2938725: [tracking issue] Track hosting provider support for PHP 7 still seems to be actively updated/maintained.

Since Drupal 9 is the only version of Drupal core that will be supported after December 2021, I think we need to be careful not to set its minimum PHP version too high. It's different from the Drupal 8 development cycle where we could require as high a PHP version as we wanted because we knew Drupal 7 was available for those that couldn't meet the minimum PHP requirement.

I looked through some of the hosting providers listed at #2938725: [tracking issue] Track hosting provider support for PHP 7 and it looks like some hosting setups are still lagging a couple years behind. Most do support at least PHP 7.1 by now, so the main thing we're going to have to worry about (for both 8.9 and 9.0) is sites that are self-hosted (especially those relying on e.g. Ubuntu LTSes). Some specifics:

• Ubuntu 16.04 shipped with 7.0 as the default PHP version and is supported until early 2021.
• 18.04 shipped with 7.2 by default and is supported until early 2023.
• Debian 9 shipped with 7.0 as the default, and its LTS coverage goes until June 2022.

The IS of #1498574: [policy, no patch] Require PHP 5.4 is an excellent template for the kind of info we probably want to gather for PHP 7 support patterns. (Please disregard the first sentence of the issue summary that says "Drupal 8 will come out in late 2013 or early 2014." 😿)

Oops, I meant to mention that one of the considerations for dropping at least PHP 7.0 support from at least 8.9 is that Symfony 4 requires a minimum of PHP 7.1.3. That means that in order to ship a version of Drupal 8 compatible with Symfony 4, 7.1.3 would need to be the minimum on both install and update. (We can still display warnings for 7.1 itself as per #20, and likewise for 7.2 starting in December 2020.)

Adding the hosting provider tracking issue as well as the Debian and Ubuntu info to the IS.

This is some unofficial (and possibly buggy) data on Drupal PHP version usage per IP that @mixologic collected in October 2018 (when PHP 5.6 and 7.0 were still officially supported by PHP for a couple more months, but PHP 5.5 was not, and when we were warning people that they should update to PHP 7 but had not yet ended our own support for 5.5 and 5.6):

I might be too optimistic, but I think I considerable amount of Debian users are using https://deb.sury.org/, I think when we switched to require PHP5, there are also still LTS versions around.

What I'm a bit confused about is whether we actually really have an option to *not* require PHP 7.1? Symfony 4 requires PHP 7.1 and we have to update to that, that's kind of the point of doing Drupal 9, so I don't see how we could not require that?

@Berdir: We need to require PHP 7.1 in Drupal 9. I think the question at hand is whether we can also require PHP 7.1 for Drupal 8.9. That would put Drupal 8.9 on safer grounds if in its lifetime a security fix of a dependency comes out that is only released for a branch of the 3rd party that requires PHP 7.1 at least.

It would not help with the Symfony 4 update in Drupal 8.8 (assuming that what we believe currently about it requiring PHP 7.1 is unavoidable) as raising the PHP requirement for 8.8 would be too late now. We should have announced it sooner.

@Gabor: Ok, I guess this paragraph confused me.

> Since Drupal 9 is the only version of Drupal core that will be supported after December 2021, I think we need to be careful not to set its minimum PHP version too high. It's different from the Drupal 8 development cycle where we could require as high a PHP version as we wanted because we knew Drupal 7 was available for those that couldn't meet the minimum PHP requirement.

I read that as a concern of requiring 7.1 in Drupal 9. But I reread the comments below now and it looks these comments were about multiple things in parallel, what to require for Drupal 8.9 and Drupal 9.0 (which is min 7.1 but could theoretically also be 7.2).

@Berdir: yeah we also don't know the PHP requirements of Symfony 5 which may be higher than 7.1. I did not find issues about that in the Symfony queue neither is the Symfony 5 branch open yet. That would factor into our decision to adopt Symfony 5 and raise the PHP version requirements (if that makes sense) or to stay with Symfony 4 in Drupal 9. We also need data to support that decision. :)

@Berdir Yeah sorry, I was thinking about two different questions that both came up during yesterday's meeting: Whether Drupal 9 could get away with requiring 7.3 or even 7.4 to avoid the fuss and disruption of dropping support for PHP versions within a major, and whether we could reasonably bump the minimum PHP version of 8.9 to support Symfony 4 compatibility as catch suggested.

As for another data point the composer stats are at https://blog.packagist.com/php-versions-stats-2019-1-edition/ 19.2% are running PHP 7.0.x or earlier. And the trends are as following:

Now that the plan is to have regular major releases of Drupal, is it possible to keep minimum version changes to major releases?

IMO we shouldnt encounter the issues faced with Drupal 6 or 7 with the new release plan and once a site has been updated to a major version it will give confidence that the site will not unintentionally break in a minor version upgrade.

@nbz: PHP goes quite fast these days. Here is a screenshot of https://www.php.net/supported-versions.php currently:

So PHP versions are supported with bug fixes for 2 years and security for another year. Let's say we release Drupal 9 with PHP 7.3 minimum requirements. That means its PHP version goes unsupported before 2022 by the PHP dev team. Linux distributions may support it longer depending on which versions their LTS shipped with. While we can take a more relaxed approach, some of our dependencies don't do that. We update minimum PHP requirements in minor releases with advance notice to avoid needing to update minimum PHP requirements if a dependency of Drupal releases a security fix on a branch requiring a PHP minimum requirement raise without making the fix available for lower PHP versions. So Drupal needs to somewhat follow its dependencies in terms of PHP version requirements.

The world is changing too fast, the only option which will always work, and dead easy to understand:

index.php

if (drupal_running_on_unsupported_php_version()) {
  die();
}

As I see, this issue is a duplicate of #2296557: [policy] Require PHP 5.5

Where the first argument is:

By requiring PHP version X, we ensure that users cannot install on unsupported versions of PHP that could contain security holes.

Before requiring 7.3, we need to be very sure both us and our upstream are fine with the new serialize behavior. I have seen bug reports on php.net and Symfony too and Drupal contrib and core #3055287: BatchStorage fails to serialize/deserialize input batch object with FormState issues as well. I guess by next summer everything will be fine but please be unusually careful requiring 7.3 this December. We are launching a site next week and we have decided to not even look at 7.3 before October -- six months after 7.3.4, to let everyone catch up.

Requiring php 7.1 in 8.9 seems reasonable.

Reparenting as a beta requirement.

7.3 support in #2938725: [tracking issue] Track hosting provider support for PHP 7 still looks spotty. It also isn't available in a default repository for Ubuntu 18 LTS.

I posted #3079791: Bump Drupal's minimum PHP version to 7.2 as soon as 9.0.x is branched (a higher version may be required later) to cover the immediate requirement of bumping to PHP 7.2 as soon as the branch opens. We can file a separate child issue to discuss what to do about 8.9.x; I'm still deeply conflicted about that one. This issue needs to remain open so that we standardize our PHP version support policy in the future.

It's worth noting that there was signficant vocal pushback about the end of PHP 5 support in 8.7.x, so I'm reluctant to drop support for 7.0 in 8.9.x for the same reasons. The usage was still really high as of May and I doubt we're going to go from 20% to 2% in a year. The counterpoints are that dropping support in 8.9.x is less disruptive than dropping it in 8.9.15 because of some hypothetical security issue with a dependency that requires 7.1+, in addition to the ease of testing/backports/etc. related to Symfony 4.

Added this to the issue summary since it was not yet reflected there:

Drupal 9 will require PHP 7.2 at least as per #3079791: Bump Drupal's minimum PHP version to 7.2 as soon as 9.0.x is branched (a higher version may be required later), however that might be raised further based on this issue later.

FWIW, I think we should consider whether a fixed minimum for php is the right way forward. This juggling act is always going to be hard because different projects have different driving challenges; trying to predict the future is doomed!

I got curious, and prepared an prediction of the phpversions chart from #38; this is purely my best guess, no additional facts available (I expect packagist folks will rebuild their actual stats in November).

In terms of vendors and hosts the version of php supplied will always be "what can we get away with"; no host (private or otherwise) is going to change without reason. In this case, therefore, a change from php7.0 to 7.1 will be because either:

- the host is enlightened enough to notice that e.g. 7.0 is EOL and they should do something (not common IMO);
- the host is being bawled at by their users (customers) to do something.

Simultaneously, users will normally follow the easy path as well, choosing the version of php by the intersection of (what is easily available and what the software they want demands). So they won't bawl to the hosts unless they need something that is not available.

I think it is therefore up to Drupal (and Symfony, and...) to keep the ball rolling.

Concretely, I would propose that:

- D8.8 should bump the min version from 7.0.8 to 7.2 on the basis that 7.0 is already EOL and 7.1 is fast approaching it. We should not condone using EOL software on a major platform.
- D8.9 should bump the min version to 7.3 on the basis that 7.3 is likely supported through most of the life of 8.9.
- We should aim to release D9 in 2020 running on 7.4, assuming it is released as intended in November 2019. This gives D9 a good platform for the future (and is incidentally around 20% faster than 7.0 according to Enrico Zimuel).

In parallel, we should make it clear that the php version will in the future be changeable on minor releases, not just major ones. In my own experience the compatibility from release to release has been good enough - most breaks have been the result of poor programming practice not the language intentionally changing to break old code.

Highly relevant to 7.4 https://discourse.ubuntu.com/t/ubuntu-server-team-update-sprint-edition-...

PHP version 7.4 is scheduled for release later this year, if you think it should (or should not) be included in Ubuntu 20.04, I’d love to hear rationale one way or another.

I do not know whether Drupal 9 should or should not require PHP 7.4, that decision is very far above my current paygrade but I think Ubuntu 20.04 shipping with 7.4 is one of the requirements for Drupal 9 doing so. Thus, if there is interest in doing this then someone should be in contact with Bryce Harrington, email is "bryce at bryceharrington dot org" (public info from the otherwise very outdated https://wiki.ubuntu.com/BryceHarrington page and also https://www.x.org/wiki/BoardOfDirectors/ and also https://cairographics.org/news/cairo-1.17.2/ ) This probably should be organized / nominated so that co/contravariant happy Drupal developers do not pig pile on the poor guy :D

In the last few months Acquia surveyed partners about what PHP versions their customers were using and what additional PHP versions were available to them (if any). There were 37 respondents. Here are the data for the PHP 7.2+ versions they had available:

(Keep in mind one organization may have multiple versions in use.)

This data is all from December 2019 when:

• PHP 7.2 was out of active bugfix support and onto security support only.
• PHP 7.3 was a year into its active support.
• PHP 7.4 had been supported for a month.

Only one respondent (3%) did not have PHP 7.2+ available at all (i.e., they were only using unsupported PHP versions). It's important to note that as Acquia partners these are generally dedicated Drupal shops, not the long tail of sites on the internet, so we can expect more attention being given to PHP version EOLs etc.

Based on #54, I think we can potentially increase Drupal 9's PHP version requirement to 7.3 because:

• More people will have adopted it by June, especially if we increase the requirement in our alpha to help drive that.
• Hosts that aren't PHP 7.3-ready can use Drupal 8.9 until they are ready to upgrade. (We have a long LTS for a reason.)
• As folks have raised above, PHP 7.2 will have barely any support lifetime left by 9.0.0.

However, before we increase the version requirement, I think we should do a call-to-action to update the data in #2938725: [tracking issue] Track hosting provider support for PHP 7, as a lot of hosts didn't support PHP 7.3 yet as of the last updates there.

I don't think we can get away with requiring PHP 7.4, unfortunately.

Oh, and here's the latest Packagist data, also from December:
https://blog.packagist.com/php-versions-stats-2019-2-edition/

BTW @rivimey's model turned out to be pretty accurate, nice work!

Also a good question is php 7.3 compatibility of conrib (at least top 100)

Responding to specific points in #51:

- D8.8 should bump the min version from 7.0.8 to 7.2 on the basis that 7.0 is already EOL and 7.1 is fast approaching it. We should not condone using EOL software on a major platform.
- D8.9 should bump the min version to 7.3 on the basis that 7.3 is likely supported through most of the life of 8.9.

My goal is actually to avoid dropping support for a PHP version between majors if at all possible. While we don't recommend using an unsupported version of PHP (literally, in the Drupal user interface, we warn them that it's not recommended), dropping support for a version of PHP means denying that site any Drupal security updates at all. I would rather they use an insecure version of PHP with a secure version of Drupal than they use an insecure version of Drupal because we dropped support for their version of PHP.

At this point it's too late to change the PHP versions supported by 8.8 or 8.9, so I think we need to instead look at how to handle the risks that using old PHP versions risks their site becoming insecure and unsupported should a dependency drop support for that PHP version and then issue a security release that's not backported to their previous version. (This almost happened with SA-CORE-2018-005; edit: corrected typo in SA #). I think that merits its own issue at this point (and I think the policy should involve (a) proactively making a plan when a production dependency drops support for PHP 7.0, 7.1, or 7.2 and (b) finding better ways to warn people and push them to update PHP to reduce the number of people who will be affected in such a scenario).

- We should aim to release D9 in 2020 running on 7.4, assuming it is released as intended in November 2019. This gives D9 a good platform for the future (and is incidentally around 20% faster than 7.0 according to Enrico Zimuel).

I would have preferred this too, because I want to set the PHP version requirement as high as possible so we don't have to deal with dependencies dropping support for the PHP versions supported by 9.0.0. Based on current data, though, I don't think it's feasible. We need to balance trying to drive change in the ecosystem with trying to make sure Drupal 9 is adopted quickly. If Drupal requires a version of PHP that a majority of hosts, distros, etc. don't use yet, it's going to result in there being little interest in 9.0.0 when it ships. That will be really dangerous for the health and adoption of Drupal as a project.

However, if we're looking at > 50% support for the PHP version we require, then we can use that as the wedge to drive further support in the ecosystem as you've suggested, especially when we have the D8 LTS to catch the many people whose hosting providers are still behind the times.

If we set the minimum required PHP version of 9.0 to 7.3, then we should define before 9.0.0 ships:

1. What we're going to do when PHP 7.3 is EOL, and
2. What we're going to do the following year when PHP 7.4 is EOL and only PHP 8 is supported, which is much worse. :(

#58 is a great question, thanks @andypost.

Keeping support for PHP 7.0 in D8.9 means that contrib modules that are meant to work both on D8 and D9, may support PHP 7.0 for the entire lifecycle of D9. That implies running tests on PHP 7.0 - and impact the possibility to support PHPUnit 8 or above. #3063887: Support PHPUnit 8 in Drupal 9, drop support for PHPUnit 7 has details. It would be lovely to get guidance/direction there.

I've opened #3106075: Bump minimum PHP for Drupal 9 to PHP 7.3. If we decide to nix it, we can do that. I don't think we can close this issue down though as this is a policy issue and I'm not sure we have the policy part of our discussions all worked out. Maybe I'm wrong.

It's likely that for Ubuntu the 20.04 LTS release will include PHP 7.3.

My goal is actually to avoid dropping support for a PHP version between majors if at all possible.

I agree with this for the reasons given in #59. And because of that, I'm +1 for raising the Drupal 9.0 requirement to PHP 7.3, because I think that's better than raising it in a later 9.x minor, and better than us having to support PHP 7.2 until November 2023 (assuming we support 9.x until the end of Symfony 4.4's support).

However, although it's good that per #64, Ubuntu 20.04 will include PHP 7.3 (or maybe higher by the time it's released?), both Ubuntu 18.04 and RHEL 8 include PHP 7.2 and will be supported until 2028 (RHEL has had a 10 year support model for a while, and Ubuntu started matching it last year). So, by raising the PHP requirement, we'll be forcing these distro users to install PHP from a separate package/stream. Unlike in the past though, this has gotten significantly easier to do, so I don't think is an unreasonable requirement, especially if it's done at the time of installing Drupal 9.0 rather than in a minor release.

What we're going to do the following year when PHP 7.4 is EOL and only PHP 8 is supported, which is much worse. :(

If we can support PHP 7.0 in Drupal 8 until November 2021 (almost 3 years past its EOL), seems like we ought to be able to support PHP 7.3 until November 2023 (only 2 years past its EOL). That's like, 1 year less headache than what we're about to deal with for PHP 7.0. I don't know how PHP 8 will change that, though if anything, I would hope that PHP would extend the support time of 7.4, as they did with 5.6. As far as I know, they haven't announced plans to do that yet, but there's also no release date set yet for PHP 8.

RHEL/Centos 8 has gone with a "streams" approach and php 7.3 is available alongside 7.2. Neither versions are installed by default.

According to https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-... php 7.2 support will be retired in May 2021 (and 7.3 in Noveember 2021).

wrt PHPUnit, please check Prohibit using PHPUnit with unsupported versions of PHP.

While I understand the logic of supporting php versions as long as possible, I don't see that the Drupal project should be actively attempting to support versions of php that the php developers are themselves not supporting.

Fundamentally people upgrade for a number of reasons:

1. because they see benefit on keeping (close to) the latest versions of packages as a policy, and so update to whatever is released;
2. because they see benefit in immediately updating for security updates and will take other updates required by that policy;
3. because they need something (eg Drupal) that depends on that package, and the Drupal now requires an update;
4. ... and won't if site is essentially abandoned or has so little effort available it might as well be;

In my experience,

1. Those in the updaters - the first group - are likely already on a recent version (eg 7.3/7.4) or are happy to move to it given a small push.
2. Those just following security patches will upgrade happily enough if you give them a strong reason to do so but won't otherwise.
3. Those in the "as needed" group will only update when forced to do so.

A lot of the long tail of old versions will, I expect, be sites that are almost abandoned, or are monitored by "as needed" people. The risk of shipping a Drupal update to a site that is running vulnerable software is significant ("Panama Papers" anyone?). Consequently we need to adopt policies that the software stack (whether Drupal Core, Contrib, PHP or otherwise) has a maintainer and is maintained.

I am therefore coming to the opinion the Drupal community should stop mollycoddling site owners and set as policy that Drupal is supported for currently-supported versions of php, and that's it. If RHEL or some other "long term" distro wants to ship php5.6+patches for some reason and still call it 5.6, then they can also ship patched Drupal.

With distros taking wildly differing stances on updates and release cycles I no longer feel it is sane to try to accommodate them all, especially given that it isn't hard to find the needed versions of packages. By sticking to the "what the php project says" stance we have a hope of defining a line in the sand that has some meaning.

@effulgentsia re:

I don't know how PHP 8 will change that, though if anything, I would hope that PHP would extend the support time of 7.4, as they did with 5.6. As far as I know, they haven't announced plans to do that yet, but there's also no release date set yet for PHP 8.

Unfortunately they've specifically pushed back multiple times and said they think they don't need to extend security coverage for 7.4 because they adopted a proper deprecation process. I don't entirely agree with them because I think that's only half the story. :P

And re:

If we can support PHP 7.0 in Drupal 8 until November 2021 (almost 3 years past its EOL), seems like we ought to be able to support PHP 7.3 until November 2023 (only 2 years past its EOL).

Another point in addition to those in #67 is that I think the pace of Composer package/ecosystem change may increase. Visually inspecting the graph in #56, it appears that it took the ecosystem a couple years to adapt to the new PHP version lifecycle, but that each subsequent version is resulting in a faster response from the ecosystem.

The amount of work that we have spent supporting older PHP versions is much less than the amount of work we've spent discussing, documenting, and implementing the actual dropping of support. The support for older versions is almost passive (except for phpunit), but dropping support takes active work.

💯

If it's possible to filter PHP version usage by only sites running 8.7.x or 8.8.x that might be useful to compare with the overall figures.

@Mixologic's semi-annual PHP version data does cover this:
https://docs.google.com/spreadsheets/d/1pPMPrlslXTCbC6z_ImsvEFBE5Yg3xWNE...

Once packaging is fixed we could ask for updated data on this and compare it to the Aug. 2019 data, to help inform our policy.

Also, generally speaking, the worst PHP language security issues we've dealt with are actually things that PHP still hasn't fixed (thinking of the phar vulnerability here). Handwaving a bit here, but many PHP-specific security issues are are already mitigated by a proper host configuration, or (as in the case of the phar stuff) mitigatble in the PHP application. I'm definitely much more concerned about vulnerabilities in Drupal itself. Also, distro LTSes are not going away, and while I certainly don't think we are obligated to support everything those distros do, we should at least accommodate them somewhat. The more technologically conservative sectors of the ecosystem (government, higher ed, finance, etc.) still tend to vastly prefer LTSes in general.

If phpunit is a bottleneck it could be replaced with soft-mocks or symfony starter, but maybe better to decouple tests more then #3067979: Exclude test files from release packages

[if] it's a choice between dropping PHP 7.3 support or staying on an unsupported minor release of a dependency

I agree that it's better for composer.lock and the tar/zip files provided on drupal.org to be on supported releases of dependencies, even if those dependency versions drop support for EOL PHP versions.

However, could we retain Drupal 9 itself continuing to work on PHP 7.3 even after composer.lock moves on to newer dependency versions? For example, perhaps by providing a composer script or plugin that could be used to downgrade dependencies to the highest version that's still compatible with PHP 7.3? The script/plugin could emit a warning about the downgraded dependencies being out of security support, and that the site owner is responsible for monitoring security announcements of those dependencies and deciding what to do when something is disclosed that isn't fixed for their version. But at least this way, the site owner can still stay on a supported version of Drupal itself and all its other dependencies.

According to @xjm:

My goal is actually to avoid dropping support for a PHP version between majors if at all possible.

If this is what we want to do then for me the question is: when is the release of Drupal 10 going to happen?

The part that I am missing in the whole discussion is that for me the choice of what the minimum PHP version that Drupal 9 should supports, for me depends on how much time there will be before the next major (Drupal 10) is released. A longer timeframe between major releases results in a higher minimum PHP version. My suggestions for the minimum PHP version compaired to the timeframe to the release of Drupal 10:
- 4 years or more, the minimum PHP version should be 7.4;
- 3 years, the minimum PHP version should be 7.3;
- 2 years, the minimum PHP version should be 7.2.

The release of Drupal 9 is very different from previous major releases, in that we now have testbots and the upgrade should be very easy for website owners. We shall learn a lot that we can use in future major releases of our project. That will result in the release of Drupal 10 being much easier for everybody working on the Drupal project.

Also the major dependecies for the Drupal project are moving to a shorter timeframe between major releases. I think it would be wise for us to do the same. I would go for releasing Drupal 10, 2 or 3 years after the release of Drupal 9.

Just my 2 cents on the issue.

@daffie: currently Drupal 10 is estimated for the middle of 2020 with a Drupal 9 EOL estimated at end of 2023 (based on Symfony 4 EOL at that time). See https://www.drupal.org/docs/9/drupal-9-release-date-and-what-it-means/ho... -- in short that sounds like it aligns with your thinking to require PHP 7.3 :)

@Gábor Hojtsy: Thank you for pointing me to https://www.drupal.org/docs/9/drupal-9-release-date-and-what-it-means/ho....

Seeing as the estimated release date for Drupal 10 will be in 2022, my vote will be for setting the minimum PHP version to 7.2 for Drupal 9. There will be only 2 years between the release of Drupal 9 and Drupal 10.

@daffie: why are you looking at dates between major releases as opposed to how long they are supported? It does not matter even if we release Drupal 10, 11, and 12 in 3 years (not going to happen just for sake of discussion), if we are still to support Drupal 9 for 4 years (also not going to happen, just to make the difference clearer).

@Gábor Hojtsy: For me there is a difference for software in active development and when it is in maintanance mode only. AFAIK development on Drupal 9 will end when Drupal 10 is released. And there is only 2 years between the release of Drupal 9 and Drupal 10. For me having PHP 7.2 as a minimum version is enough.
There will be third parties that will support Drupal 9 long after november 2023, which is when Drupal 9 is EOL for the Drupal project.
I can understand that from a operational side of the software business you might have a different perspective. I am not trying to offend anyone. I am just looking at it from a developer perspective.

As the Drupal releases must be synchronized with Symfony LTS releases, my first question would be: which PHP version is supported by SF4.4 and how long?

I can answer that: https://github.com/symfony/symfony/blob/4.4/composer.json#L19 PHP 7.1.3 and https://symfony.com/releases three years.

We are good on that front because we are going 7.2.

At this point it's too late to change the PHP versions supported by 8.8 or 8.9

Based on this comment, I'm setting this issue's Version to 9.0.x.

Meanwhile, #3106075: Bump minimum PHP for Drupal 9 to PHP 7.3 got committed, so raising 9.0's requirement to PHP 7.3 is done.

Therefore, I think all that's left for this issue is:

Again it's only a potential issue, but if we get to the end of 2021 and it's a choice between dropping PHP 7.3 support or staying on an unsupported minor release of a dependency, it'd be better if we say EOL PHP version support is best effort than explicitly committing to supporting it now.

Related to that, I'm still curious if #75 is at all feasible.

Retitling accordingly. We could probably use an IS update as well.

Worth noting, Packagist now provides PHP version statistics for each package.
https://packagist.org/packages/drupal/core/php-stats

Thanks for sharing that @Chi, that's pretty cool! I really like well-presented data in graphs.

Looks Debian 11 removed PHP 8 in freeze https://lists.debian.org/debian-release/2021/02/msg00152.html

Rescoping to include the ongoing policy rather than just the specific 7.3 requirement, as suggested by @quietone.

Oops, we actually have #3223443: [policy, no patch] Process for dealing with EOL PHP versions during the Drupal 10 and future release cycles for the generic case. So let's turn this into an implementation issue for D9 specifically -- which we actually sorta need to solve ASAP.

Updating Debian and Ubuntu release info

Since PHP 7.3 is now EOL and there is a chance that one of our dependencies might drop support for it between now and when 9.4 is EOL in November 2023, we need to do whatever we're going to do here soon. Certainly in advance of 9.4.0-beta1, but we should actually address it ASAP since any solution we pick is at least somewhat disruptive. (When PHP 5 support was deprecated, we only introduced the new message in a new minor, alongside lots of comms, with a year-plus of gradually increasing warnings and announcements.)

So, I'm rescoping this to be an implementation issue specifically for Drupal 9.

As @catch pointed out, we have an API still in core to gradually drop support PHP versions -- a series of constants we've retained since the PHP 5 support deprecation. Basically, that approach would involve increasing MINIMUM_SUPPORTED_PHP. I'll open an MR for that potential resolution shortly to get us started, and will document what it does and what the drawbacks are.

Pushed the MR.

History of PHP requirements for Drupal 9

1. Here is the current text in the system requirements docs:
   https://www.drupal.org/docs/system-requirements/php-requirements#php_req...

 

2. Here's the only thing the 9.0.0 release notes said about the PHP version requirement:

   Drupal 9 requires PHP 7.3 or higher, and the version requirement for Apache has been increased to Apache 2.4.7 or higher.

    

3. The only CR for any D9 branch about it: https://www.drupal.org/node/3089166
    

4. Drupal 8.9 and 9.0 were not compatible with PHP 8; in fact we explicitly had to indicate they were incompatible:
   https://www.drupal.org/node/3180764
    

5. The recommended PHP version was increased in 9.2.x to 7.4 (#3214920: Increase DRUPAL_RECOMMENDED_PHP to 7.4), and again in 9.3.x to 8.0 (#3214924: Increase DRUPAL_RECOMMENDED_PHP to 8.0 in Drupal 9.3 or 9.4). Neither issue even had a CR. (They probably should have.)
    

6. Here's what HEAD does currently on PHP 7.3.
   
    

If MINIMUM_SUPPORTED_PHP were increased to PHP 7.4 as in the MR branch

This is what our least disruptive option would be with the existing API. This option would prevent installation on PHP 7.3, which is a highly disruptive change. (We gave a year's notice prior to making a similar change for PHP 5.)

1. If a user tries to install a new site on PHP either vial CLI tools or the UI installer, they will get the following error, and installation will not continue:

     PHP: 7.3.33                                                                                    
                                                                                                    
     Your PHP installation is too old. Drupal requires at least PHP <em class="placeholder">7.4.0<  
     /em>. It is recommended to upgrade to PHP version <em class="placeholder">8.0</em> or higher   
     for the best ongoing support. See <a href="http://php.net/supported-versions.php">PHP's versi  
     on support documentation</a> and the <a href="https://www.drupal.org/docs/9/how-drupal-9-is-m  
     ade-and-what-is-included/environment-requirements-of-drupal-9#s-php-version-requirement">Envi  
     ronment requirements of Drupal 9</a> page for more information. 
   

    

2. It results in the following changes on the status report:
   
    

3. Without an update hook, the user is not prompted to run update.php. If we added an empty update hook, the user would see:
   
    

4. If the user updates the DB with drush instead, they will see:

   [ayrton:drupal_test_site | Sat 20:27:59] $ vendor/bin/drush updb
    [warning] Your PHP installation is too old. Drupal requires at least PHP /7.4.0/. It is 
   recommended to upgrade to PHP version /8.0/ or higher for the best ongoing 
   support. See PHP's version support documentation [1] and the Environment 
   requirements of Drupal 9 [2] page for more information.
   
   [1] http://php.net/supported-versions.php
   [2] https://www.drupal.org/docs/9/how-drupal-9-is-made-and-what-is-included/environment-requirements-of-drupal-9#s-php-version-requirement
    (Currently using PHP 7.3.33
   )
   

   ... but this itself will not pause or interrupt the update, and most deployments will only have this message amidst a stream of other CLI output.
    

5. Nothing in the composer requirements or update process is changed, because we have to still allow the build on 7.3 for existing sites with MINIMUM_SUPPORTED_PHP. (Some devs complained about this when we used the same process for PHP 5.) It would be feasible to add custom Composer warnings for unmet Drupal system requirements, but we've not done that before for PHP version requirements.
    

Points to consider

1. Is preventing new sites from being installed on PHP 7.3 too disruptive on ≈4 months' notice?
    

2. Should we add more specific language both to core and the system requirements page about how running an old PHP version puts a site at risk of not being able to apply future security updates?
    

3. Should system requirements warnings and errors be exposed via Composer integration?
    

4. What steps will we take if a dependency does drop PHP 7.3 support between now and Nov. 2023?
    

5. What, if anything, should we do about PHP 7.4? It's EOL in Nov. 2022, a full year before 9.4's EOL, so there is technically a (very small) risk of something dropping support within that year as well. If we're going to do anything beyond the current message on the status report about PHP 8.0 being recommended, even making a different info message, we need to do it before 9.4.0-beta1. (If we put it in a patch release, many sites might not actually see the message promptly.)
    

6. Should we backport anything to 9.3? In Drupal 8, new warnings about PHP 5's EOL were reverted from the production branch at the product managers' requests because they were considered too disruptive. (See #2670966: Warn users of old PHP versions and #2927344: Specifically warn about end dates for PHP support for old versions.)

If 9.4 will be our last 9.x minor, then what do we gain by preventing new sites from installing on PHP 7.3 if we still have to support old sites on it?

If one of our dependencies drops PHP 7.3 support, do we think they'll do it in a new minor release, or in a patch release? If they do it in a new minor release and they do it after Drupal 9.4.0 is released, would we update to that new minor in a Drupal patch release even if we didn't have to support PHP 7.3, or are we going to be stuck on old minors of our dependencies regardless of PHP compatibility issues?

Great points to consider!

1. It makes sense to prevent installing new sides but it also affects existing sites that using install from existing config. I find it too disruptive.

Actually security depends not on PHP version string but hosting provider's platform, Debian/RH could backport backfixes for years, and it's the primary blocker to adopt new language features (like native attributes) see the choices #3173787-35: [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) as they affect 9.x core too

2. core could only convince using newer version for the same reason, and security consideration not at core/php level - servers/hostings are very different nowadays (everyone can build php with insecure patches and package it to public docker registry)

3. as drupal/core require "php": ">=7.3.0", and can't be used without composer it sounds good idea, IIRC auto-updates initiative using composer a lot and probably has checks for platform requirements

4. at Nov'23 PHP 8.0 also loosing security support, looks too tricky because PHP providers may vary too

5. I find warning at status report is good indicator to notify users about running unsupported (from PHP POV) version but it could be secured by hosting provider (maybe it needs setting to disable warning)

6. We could backport warning about running unsupported version - PHP release cycle is annually stable and predictable, so its easy to backport list of php-supported-versions.

Thanks @effulgentsia and @andypost!

Re: #98:

If 9.4 will be our last 9.x minor, then what do we gain by preventing new sites from installing on PHP 7.3 if we still have to support old sites on it?

Yeah, I'm not sure we gain anything by it; it's just what the existing API does. (It made more sense when we didn't even have any plans to EOL D8 at the time it was added.) We might want to (a) add to the current API, (b) change the current API's specific behaviors in a BC way, or (c) implement some one-off requirements warnings etc. for Drupal 9 specifically, and then change how the API works in D10.

If one of our dependencies drops PHP 7.3 support, do we think they'll do it in a new minor release, or in a patch release? If they do it in a new minor release and they do it after Drupal 9.4.0 is released, would we update to that new minor in a Drupal patch release even if we didn't have to support PHP 7.3, or are we going to be stuck on old minors of our dependencies regardless of PHP compatibility issues?

Zend Feed and Diactoros both dropped PHP 5.5 support in minor releases within less than one year of PHP 5.5's EOL, and simultaneously ended security coverage for earlier minors that had supported it. That's why we came within a hair's breadth of having to break PHP 5.5 support with no warning in SA-CORE-2018-005 and just barely avoided it because we coincidentally only exercised the vulnerability via Symfony code. (We left the Zend packages on the unsupported release until our scheduled PHP 5.5 support end date eight months later, but it could easily have gone the other way. That was also before core-recommended.)

While the Laminas packages are being deprecated as core dependencies, even our most reliable dependencies like Guzzle only provide security support for the most recent minor versions. (To my knowledge, Symfony is the only dependency we have that does provide security coverage for the previous minor, and even then we're supplementing their security team with two of our framework managers to get a full 12 months' security coverage for the components we use.)

In another past example, we had to do a minor update from Guzzle 6.1 to 6.2 on a security window for SA-CORE-2016-003 because we did exercise the vulnerable code and they would not backport the fix to a 6.1 patch release. It's entirely possible and even likely we'll run into another need to do a minor update for a dependency during an LTS. (Put another way, it's more important for sites not to have critical vulnerabilities than it is for sites to not have any minor dependency updates during an LTS.)

Guzzle also considered dropping PHP 5 support in a minor release of Guzzle 6, so it's entirely possible they might also drop support for PHP 7.3 in Guzzle 6 as well. (Guzzle is just an example; this could happen with any PHP dependency.) If that happened, and Guzzle also had a security release afterward, we'd be in a bad spot. PHP dependencies are much more likely to have RCE or other critical and highly critical vulnerabilities that would be urgent to update immediately without taking the time to try to write our own migation.

Even if we try to come up with clever overriding backports like we've done with jQuery minors, core-recommended would still be incompatible with the hypothetical secure version of Guzzle unless we also increased our PHP requirement to whatever PHP version they required. This means we'd be forcing the site owner to either run a vulnerable version of Guzzle in their application (which be exposed in other code paths even if we mitigated core's), or to update their platform PHP version during a security window, which is at least an order of magnitude worse than a major dependency update. Same for whatever other hypothetical PHP dependency.

Finally, even for dependencies that only drop support for PHP versions in majors, they might choose to EOL those old majors in response to PHP 7.3's EOL. No one other than Symfony and CKEditor has made any commitments to retain support for the versions Drupal 9 is using through November 2023 (in many cases we've specifically asked), and no one besides us and Symfony has any sort of scheduled release cycle. (I wish they did!)

So the thing we need to warn site owners about is that if they don't upgrade to the recommended PHP version, then there is a risk they won't be able to install future security updates. Or in other words, we can only guarantee security coverage if they install the PHP versions that PHP is still supporting.

Re: #99:

1. It makes sense to prevent installing new sides but it also affects existing sites that using install from existing config. I find it too disruptive.

Yep, that's my primary concern with it as well.

4. at Nov'23 PHP 8.0 also loosing security support, looks too tricky because PHP providers may vary too

Well, Drupal 9 is also EOL then, so it's not a concern for this issue. :) (It is a concern for #3223443: [policy, no patch] Process for dealing with EOL PHP versions during the Drupal 10 and future release cycles, but we can change policy for D10 without the same disruption that it is for a D9 minor.)

5. I find warning at status report is good indicator to notify users about running unsupported (from PHP POV) version but it could be secured by hosting provider (maybe it needs setting to disable warning)

Even if PHP itself is secure via the distros' patches, using that old PHP version might prevent them from installing a secure version of a Composer package that has dropped support for the old PHP version. (See my replies above to @effulgentsia's comments.) If it weren't for the stuff with dependencies, we could safely ignore the issue or constrain it to suppressable informational messages. Edit: It's actually even more important to warn those site owners, because they would reasonably expect that the LTS's security coverage for PHP was enough, rather than anticipating that some other dependency could still cause them to lose security support.

Of note: Based on https://packagist.org/packages/drupal/core/php-stats#9, it looks like nearly 20% of sites are still using PHP 7.3. So one in five Drupal sites will be affected by whatever we do in 9.4.

My MR commit in the previous comment is a rough sketch of what might be a better solution. It changes the current API behavior slightly so that installation and update treat MINIMUM_SUPPORTED_PHP the same way (both will trigger warnings, rather than errors). Since what's a new install vs. an update is blurred by various deployment workflows, it's maybe legacy thinking to treat the two cases differently.

(The MR will probably fail a few tests that test the currently expected error behavior.)

I'd consider this an allowed change in a D9 minor: While it is technically a behavior change for the API itself, it's not a behavior change for the current values, since 9.0.0-9.3.0 have MINIMUM_PHP equal to MINIMUM_SUPPORTED_PHP. Contrib would have to be subclassing core/lib/Drupal.php to change the constant value, and most workflow tools for installation should be relying on core's error handling.

Here's what #103 would look like in the UI installer:

The site owner can then click the "continue anyway" link at the end of the installer and still install despite our advice.

Currently, neither the quick-start command nor Drush display installation warnings, so we'd want to patch the quick-start command for that (maybe in this issue) and file a followup with Drush as well to get them to pass on the warnings.

Would we want to do something like say that 9.4 will be the last version that works on PHP 7.3 (in terms of Composer constraints), but that we might release a 9.5 at some point (e.g., either December 2022 or June 2023) that updates our vendor libraries to their non-EOL versions, which might require PHP 7.4 or 8.0 (we don't know which, it will depend on how aggressive our dependencies will be in dropping PHP 7 support)?

And that at that point, we'll support 9.5 until Nov. 2023 and will support 9.4 until either Nov. 2023 or until there's a critical security vulnerability in one of its dependencies that we're unable to backport to 9.4 or provide mitigations for it, at which point, we'll mark 9.4 as no longer security supported.

Not sure if that would help communicate the situation better to site owners vs. just making breaking changes in a 9.4 patch release?

#106 is worth considering if we can communicate it effectively. It'd be a bit fiddly -- i.e., 9.5 (or 9.6 in the December release scenario) might increase a dependency and PHP requirement, but 9.4 could still have security support until either the EOL or until there were a non-PHP-whatever-compatible security update. (That could also be a solution that would potentially enable longer LTSes in the future as well, since the main risk for a long LTS is also related to the dependency support problem.) The downside is that any non-fixed schedule will feel less reliable and is harder to communicate, but it's an option.

Tagging for a followup for the quick-start command and another for Drush. We could also file a followup to make the text clear about whatever specific policy we adopt. (We deliberately made it vague in Dupal 9 to cover our bases since we did not know yet exactly what the policy would be.)

Updating the IS with a current problem statement and the new proposed resolution.

Posted the core and docs followups for this issue (not the Drush followup yet).

Also noticed #3261611: Fix PHP requirements link and standardize the strings that reference it in the process of re-reviewing this, which should probably be a separate scope that we can fix first. This will need the MR updated once that lands.

There's a developer concern here: core started adding return types. That argues extremely heavily in favor of dropping PHP 7.3: https://3v4l.org/UPuUq (it seems the technical term here is covariance according to the manual). PHP 7.2 had (limited) contravariance support but covariance support was only added in PHP 7.4.

If core continues to support 7.3 in 9.4 which will be supported for quite some time maybe it could consider removing return types and re-introduce those in Drupal 10. Well, re-introducing would require no action as it's already in git. It certainly would make backporting patches harder. Potentially, however, a single removal shortly before releasing 9.4 would maybe easier? Note I should have said object return types because I believe this does not affect scalar typehints as PHP 7 had no ways to "widen" a scalar type (that's a PHP 8 feature with union types). There are, as far as I am able to tell, only 84 object type hints outside of test code, the vast majority added in 9.3.x -- 9.2.x had 10, 9.3.x had 77. (Of course, it's possible my meager efforts to grep these are incorrect and a proper PHP parser based search would find more.)

Also, as far as I can tell, removing return type hints would cause no backwards compatibility issues with existing D9 modules: https://3v4l.org/YDrXB -- this is the same code as the first link, except the foo::test method no longer has a return typehint. The extending bar::test kept its typehint.

I fully realize it would've been better if I raised this concern earlier but I only started using D9 when D8 went EOL and so D9.3 was out before I realized what's going on and while I follow the core change notices on Twitter, it seems there is no change notice about this, I searched for hint.

Also, https://www.drupal.org/docs/develop/standards/object-oriented-code#hinting doesn't mention return types while https://www.drupal.org/docs/develop/standards/coding-standards#s-paramet... does.

@Charlie ChX Negyesi, that is out of scope here. Could you file a separate issue if you would like to discuss it? Thanks!

Just realized one of the screenshots had an out-of-date comment on it; fixing here.

I am not sure how it is out of scope when it is an reason to raise to 7.4. If the decision is already made to stay on 7.3 then yes, removing those is a separate issue. Sorry if I missed it but I haven't realized the decision is already made.

@Charlie ChX Negyesi Regardless of the approach we take, new PHP-version-specific syntax will not be backported to Drupal 9. We also certainly are not backporting massive, patch-and-MR-disrupting coding standards changes and loosenings of APIs to Drupal 9.

D9 will be end-of-life in November 2023, and this is a hard deadline because of Symfony 4.4's end-of-life. It's also not open season on big cleanups or feature additions anymore, because 9.4 is the final, 10.0-API-compatible version of Drupal 9. (The only reason we're allowing API additions or deprecations at all is that there are too many outstanding hard- and soft-blockers for Drupal 10 in #3118154: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 10 core by 9.4.0-beta1, so there was no point in making a list of like 30 exceptions to the feature freeze.) :P

MINIMUM_PHP is still 7.3.0, and HEAD is tested against multiple PHP 7.3 environments. In fact, we have to revert something about once a month because someone's PHP 7.4 syntax slips through and DrupalCI consequently begins spamming me. ;) I myself accidentally added a class typehint to a protected property (a PHP 7.4 feature) in an MR just this week, and it took about 90 seconds for CI to tell me "BZZZT, nope, sorry!" :)

In the past, we required announcing an increase of MINIMUM_PHP a year in advance. (Actually we announced it more than a year ahead of time, then increased MINIMUM_SUPPORTED_PHP in the announced minor, and only increased MINIMUM_PHP another 6 months later in the next minor after that one). Drupal 9.4 is the last minor of Drupal 9, and it goes into beta in three months. ;) So that's not enough time to increase MINIMUM_PHP when we haven't even come to a decision here, and why the proposed resolution only increases MINIMUM_SUPPORTED_PHP.

Even if MINIMUM_PHP had to be increased in response to a dependency update (possibly in an unscheduled minor as mentioned in #106 and #107), the branch would still only be receiving minimal bugfix and security support -- not any API additions or cleanups that might break PHP 7.3, and not changes to coding standards generally.

So, this issue is only about risk management for the hypothetical scenario where one of our dependencies drops PHP 7.3 support between now and November 2023.

Hope that helps clarify! Thanks.

I understand then that this issue is not about an imminent version change, I will go and file a separate issue.

#3262620: Object return typehints are a serious problem for developers PHP <7.4, remove from D9

Oh, I forgot to mention that we still have to backport security fixes to 9.2.x now and 9.3.x until December 2022, which is part of why we wouldn't add syntax to 9.4.x that wouldn't work on those branches -- it could get in the way of shipping security releases if we do. Thanks!

#96:

Is preventing new sites from being installed on PHP 7.3 too disruptive on ≈4 months' notice?

I think we can reasonably assume that hosting providers that they inform their customers that PHP 7.3 will soon be unsupported. Drupal is not the only only responsible to inform users. IMHO the fact that Drupal's dependencies are completely within reason to drop PHP 7.3 support alone is reason enough to require 7.4. This bit from @xjm's reply in #100 also aptly describes the indirect risks:

Even if PHP itself is secure via the distros' patches, using that old PHP version might prevent them from installing a secure version of a Composer package that has dropped support for the old PHP version.

#98:

If 9.4 will be our last 9.x minor, then what do we gain by preventing new sites from installing on PHP 7.3 if we still have to support old sites on it?

Yeah, I'm not sure we gain anything by it; it's just what the existing API does.

Don't we gain one crucial thing? Not having to maintain forks of unsupported dependencies that dropped 7.3 support?

#100:

No one other than Symfony and CKEditor has made any commitments to retain support for the versions Drupal 9 is using through November 2023 (in many cases we've specifically asked)

😱

#101: So one in five Drupal sites will be affected by whatever we do in 9.4. → but we have no idea what fraction of those are simply testing against PHP 7.3 for CI purposes. For example, Drupal CI alone probably accounts for a solid portion of those numbers.

#102 It's much better to cause some PHP version annoyance for sites (existing and new) before that happens, than on the day the security release comes out. → 💯 — we should make this our policy, which would help avoid having this kind of discussion as frequently as we do right now. EDIT: that's basically what @xjm proposes in #3261447: Add an API for dynamically setting recommended and supported PHP versions based on known and predicted PHP release schedules 🚀

I can't think of anything to add to the thorough discussion 👆. I think the only rational choice here is to require PHP 7.4 in Drupal 9.4.

#101: So one in five Drupal sites will be affected by whatever we do in 9.4. → but we have no idea what fraction of those are simply testing against PHP 7.3 for CI purposes. For example, Drupal CI alone probably accounts for a solid portion of those numbers.

Ahh, but the PHP 7.3 environments only run on commit, so it's actually only a handful a day that could conceivably be in the Packagist data. If anything, we'd expect bloated PHP 8 numbers, because that's where patches get tested. ;)

Great writeup; thanks @Wim Leers!

#101: So one in five Drupal sites will be affected by whatever we do in 9.4. → but we have no idea what fraction of those are simply testing against PHP 7.3 for CI purposes. For example, Drupal CI alone probably accounts for a solid portion of those numbers.

Exactly what I thought. This will be very interesting times in 2022!

Updating the IS with the current proposal for what would happen for sites using the old PHP version. Specific implementation details are in #3261606: Provide more specific messaging about the consequences of using an unsupported PHP version.

From a governance perspective, this at least needs explicit release management signoff, which we'll post so long as @catch and @quietone don't have any outstanding concerns with this approach. Not sure whether this technically needs product and framework signoff, but it would be good to have them explicitly since this does represent a change to the implementation details of the release cycle.

Re: #129, yeah, we can hardly call 9.4.x an "LTS" anymore anyway since it's probably only going to be supported for 14.5 months (or maybe only 11 months if it ends up being 9.5.x). So I think we need to change how we describe it regardless.

We can, however, still call it the final scheduled minor release of the major series.

Started with this for now:
https://www.drupal.org/node/2383987/revisions/view/12536650/12554341

Additionally made these changes:

• https://www.drupal.org/node/3090184/revisions/view/12495955/12554328
• https://www.drupal.org/node/2941566/revisions/view/12085433/12554331
• https://www.drupal.org/node/721106/revisions/view/12494243/12554333

All other references to "LTS" or "long-term support" in the handbook are references to one of:

• 8.9 specifically,
• LTSes of other software (e.g. Ubuntu, Node.js), or
• the D6 LTS program.

And, finally, added a draft section to the PHP requirements page:
https://www.drupal.org/docs/system-requirements/php-requirements#s-what-...

Also added a link to the info on supported PHP versions from the bit on the release cycle overview that talks about security coverage:
https://www.drupal.org/node/2383987/revisions/view/12554341/12554366

I've read the issue and pondered and re-read and I agree with the proposed resolution.

And I too would like to thank @Wim Leers for his clear summary, which helped pull the pieces together for me.

I am a little fuzzy on saying that the LTS is the final scheduled minor release. It seems to me that if a minor release is made only because a dependency dropped support for a PHP version then it is not a scheduled release.

Just one question about implementation. How will do step 4. "We monitor Drupal 9 dependencies' PHP version support from now until the Drupal 9 end-of-life."? Will that be a [tracking] issue like the PHP one or something else.

Yep, agreed with #136.

Regarding:

Just one question about implementation. How will do step 4. "We monitor Drupal 9 dependencies' PHP version support from now until the Drupal 9 end-of-life."? Will that be a [tracking] issue like the PHP one or something else.

I was wondering this too. Min/max testing would help a lot, but it would only get us so far here. The PHP constraint itself will prevent the update on lower PHP version environments. A dependency could also create a new major version with a new PHP requirement, and our constraints wouldn't allow that update. So we'd need to figure some process out. Part of that could be getting more complete dependency information on the core dependency handbook page so we can use that as a central place to check. We'll want to look at a combination of documentation for the projects (which we link to from that handbook page), and the Composer updates available for each package.

We've had mixed success faking min/max testing for updates in the RTBC queue, and we've been pretty successful at getting Composer deps updated before a minor release. I'd enlist the help of folks who contribute to those issues to also monitor for new minor or major releases that might include changes to PHP requirements.

I don't think that blocks this issue, though, just something to figure out in the followup.

@catch, @xjm, thank you both for the clarification. I am still in agreement with the proposal.

Still needs a follow-up for Drush (see #108) but otherwise I think the proposal is sound and has agreement from the release managers.

Thanks @tim.plunkett!

@catch, @quietone, and I agreed that this issue has release management signoff.

@alexpott, @larowlan, and I agreed that this issue has framework management signoff as well.

OK, this is unfortunately blocked on figuring out WTF is going on with the test runner. Somehow I kept forgetting to queue a PHP 7.3 test job for this and they're mysteriously not working.

During Drupal 8 we added MINIMUM_SUPPORTED_PHP and a bunch of test APIs related to it so that we could deprecate PHP 5.5 and 5.6 support while still providing test coverage for them. This same API is being reused here. However, the tests changes I mention aren't even coming into play because the tests aren't getting that far.

What's happening is that the test runner is hanging indefinitely at the end of the unit test job. Where the console output of a normal test run says this:

20:01:13 Drupal\Tests\Core\Security\RequestSanitizerTest               43 passes                                      
20:01:17 Drupal\Tests\Core\Test\PhpUnitCliTest                          1 passes                                      
20:01:17 Drupal\Tests\Scripts\TestSiteApplicationTest                   7 passes                                      
20:01:21 Drupal\Tests\Core\Command\GenerateThemeTest                    3 passes                                      
20:01:39 
20:01:39 Test run duration: 1 min
20:01:39 
20:01:39 Attempting to connect to database server.
20:01:39 Database is active.
20:01:40 Reformatted junitxml test results saved
[... a bunch of chmod and cd and etc. ...]
20:01:41 chown -R 1001:1001 /var/lib/drupalci/artifacts
20:01:41 ---------------- Finished run_tests.phpunit in 71.408 seconds ---------------- 
20:01:41 ----------------   Starting run_tests.kernel   ----------------

... and then the kernel tests run happily from there.

However, with this patch, on any PHP 7.3 environment, this happens:

19:21:32 Drupal\Tests\Core\Security\RequestSanitizerTest               43 passes                                      
19:21:34 Drupal\Tests\Scripts\TestSiteApplicationTest                   7 passes                                      
19:21:39 Drupal\Tests\Core\Test\PhpUnitCliTest                          1 passes                                      
19:21:40 Drupal\Tests\Core\Command\GenerateThemeTest                    3 passes                                      
[...loading gif...]

And that's it. It's stuck there until the job times out after 110 minutes.

Other facts:

• It happens on every PHP 7.3 environment regardless of the database used.
• It's definitely related to this issue. I requeued a PHP 7.3 job for HEAD, and it was able to continue on to the kernel tests.
• It's definitely related to PHP 7.3. I queued PHP 7.4 8.0 jobw for this MR, and both were able to continue on to the kernel tests.
• I can run an arbitrary kernel test locally with PHP 7.3 and this MR with no problem.
• I can run the final unit test Drupal\Tests\Core\Command\GenerateThemeTest locally with no trouble.
• Drupal installs and runs fine on PHP 7.3; all the screenshots in the IS were made with an actual site with actual PHP 7.3 that was working fine. I even created new fake releases locally and ran update.php etc. to make those screenshots. Used real drush. Etc.
• I found nothing relevant in the console log or build artifacts on Drupal CI.

Stumped.

This:

--- a/core/modules/system/system.install
+++ b/core/modules/system/system.install
@@ -294,7 +294,7 @@ function system_requirements($phase) {
         ':php_requirements' => 'https://www.drupal.org/docs/9/how-drupal-9-is-made-and-what-is-included/environment-requirements-of-drupal-9#s-php-version-requirement',
       ]
     );
-    $requirements['php']['severity'] = REQUIREMENT_ERROR;
+    $requirements['php']['severity'] = REQUIREMENT_WARNING;

makes the while-loop in in Drupal\Tests\Core\Command\QuickStartTest::testPhpRequirement() waiting on the return of a non-existing error until the end of the world.

By default warnings aren't shown for non-interactive installations: https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/includes/ins...

I've altered the test to use 'install standard' instead of `quick-start` (like the other tests in this class) which makes the install shorter and got rid of the while loop.

The choice if we want to display the (now) warning message and alter the ::testPhpRequirement() test accordingly or drop the whole test since there's no error message any more, is something I'll happily leave to Bigger Brains.

Leaving this on Needs work for the above reason.

@Spokje, great find! I admit I did not pay much attention to those tests when I did a find-and-replace. And I didn't even think of it despite complaining about the lack of warnings from quick-start in #104. Should be easy enough to fix.

A (very) quick spot-check on the 6 test-failures for the PHP 7.3 runs seem all related to the now warning instead of error for the minimum PHP version.

I'm going to split off a separate scope of issue to deal with fixing QuickStartTest. The timeout there clearly isn't working as intended. There is a missing $process->checkTimeout();.

#3265291: QuickStartTest: The waiting is the hardest part... is that issue; we have two possible approaches so could use feedback on which direction to go.

Also split off #3265325: Raise a warning instead of an error when installing on MINIMUM_SUPPORTED_PHP since there's apparently other tests to fix for that.

So yeah, HEAD has regressed and has five total tests (three individual tests and a base class for two more) that are not compatible with MINIMUM_SUPPORTED_PHP. Once those are fixed, QuickStartTest needs to be updated for the new behavior of allowing installation on MINIMUM_SUPPORTED_PHP. So, this is blocked on:

1. #3265376: Fix UpdateScriptTest when MINIMUM_SUPPORTED_PHP is used
2. #3265377: Fix LocaleTranslatedSchemaDefinitionTest when MINIMUM_SUPPORTED_PHP is used
3. #3265378: Fix NoPreExistingSchemaUpdateTest when MINIMUM_SUPPORTED_PHP is used
4. #3265325: Raise a warning instead of an error when installing on MINIMUM_SUPPORTED_PHP

We could still use product manager input on the approach in the meanwhile.

The three various test failures are resolved now, so #3265325: Raise a warning instead of an error when installing on MINIMUM_SUPPORTED_PHP is unblocked and ready for review.

Edit: #3265377: Fix LocaleTranslatedSchemaDefinitionTest when MINIMUM_SUPPORTED_PHP is used is actually only RTBC ATM, but soon. :)

#125:

Ahh, but the PHP 7.3 environments only run on commit, so it's actually only a handful a day that could conceivably be in the Packagist data.

I was going to point to the CDN module as an example (https://www.drupal.org/node/206147/qa), but … I see now that it says testing configuration no longer available — I did not realize that! Would've been great if maintainers had been notified of this 😅

#135: you're welcome! I didn't realize my comment would be that helpful, but am glad to hear that! 😊

#144: wow, epic test debugging right there, @Spokje! :D

#3265376: Fix UpdateScriptTest when MINIMUM_SUPPORTED_PHP is used landed (the first blocker in #150), #3265377: Fix LocaleTranslatedSchemaDefinitionTest when MINIMUM_SUPPORTED_PHP is used is RTBC (#150.2), #3265378: Fix NoPreExistingSchemaUpdateTest when MINIMUM_SUPPORTED_PHP is used landed (#150.3).

I am a Drupal core product manager. I agree with the code changes proposed in the issue, however I do not believe the criteria for releasing a 9.5 (and consequently a 9.6, 9.7, etc. are quite clear). Multiple dependencies could be changing, prompting newer and newer minor versions. I don't see that factored in, or the potential quick succession of these and lack of support to prior minor versions then. That I think is more of a policy question than a code change, so not sure why that is coupled into this issue.

My interpretation of item #5 in the proposed resolution is that Drupal 9.5 would be released if and when the PHP requirement needs to be raised from PHP 7.3 to 7.4 (because a dependency requires that to remain security supported). After the first dependency causes that situation, updating other dependencies would not require another PHP requirement change, so would not necessitate a Drupal 9.6.

Maybe the wording of that item could be clearer?

This is the current text of that section:

If:

• A dependency drops support for PHP 7.3, and
• The dependency also no longer supports previous versions that were compatible with PHP 7.3

Then:

• A new minor version of core (e.g., Drupal 9.5) is created that increases the minimum PHP requirement and the constraint for the affected dependency.
• Old Drupal core minors (e.g., 9.3 and 9.4) are considered unsupported.
• Security fixes are still backported to the old Drupal core minors only for security advisories that do not involve the affected dependency.

Since further dependencies could further update constraints, I don't know how would this stop at the first dependency? It is also possible that certain dependencies drop support for PHP 7 altogether (later).

@catch in your example, what happens if we are on 9.5 (after your point 1 or 2) and anothet dependency drops support for the major version we use that still supported 7.3 and the new major version only supports 7.4. The PHP requirement would not change but the update would not fit into our semver rules, so we would need to then also raise to 9.6? And 9.7, 9.8, etc. onwards for further similar dependencies? Since the lack of PHP 7.3 (or later 7.4) support triggers the major dependency update, I think that situation belongs in this issue as well.

Ok, just wanted us to be clear about the possibility of Drupal 9.6, 9.7, etc. in case of these dependency moves. I understand we want to make the releases sooner than later when we need to, but it may make sense to figure out some buffer time in case we can bundle multiple dependencies. The way its defined in the issue summary it will be mostly instant, so may result in various new Drupal 9 minors if multiple dependencies move on from PHP 7.3 and 7.4 a couple months apart. I think that is realistic since PHP 7 community support ends later this year. So I think the plan/policy would need some fine tuning in that area to balance the security needs with the inconvenience caused by a possible quick succession of new Drupal 9 minor releases. But that in itself should not stop from the code changes proposed here from landing. So I am removing the needs product manager review tag.

Agreed with #157 and #159 in general.

Maybe we could set an upward bound of one new minor per (say) three months? And one dependency dropping PHP 7.3 support or 7.4 support automatically triggers an audit of the rest of the dependencies' forward branches to see if there are other dependencies that we should try to bundle that are changing the requirement in the same way? I agree that having a flurry of new minors would not be ideal; I was taking it for granted that we would be sensible about it but it doesn't hurt to be explicit. ;)

Added an additional followup task to track the dependency PHP version requirements (possibly on the dependency handbook page).

Unpostponed now.I'll update the MR.

New MR should do the trick. Much simpler to fix with the installer warnings already happening in a second issue. :)

I ran a bit of a [ayrton:drupal | Mon 09:25:22] $ grep -r "7\.3" * | grep -vi "svg' | grep -v "vendor" and the other places we have reference to PHP 7.3 are in the composer constraints -- not only the minimum composer constraint for core, but constraints in the composer.json that core/lib/Drupal/Component seem to have as well. However, the composer constraint stays with MINIMUM_PHP (which remains 7.3 with this issue), not MINIMUM_SUPPORTED_PHP, so that's correct here.

Of note, the Component composer.json PHP versions didn't get updated to PHP 8.1 along with the rest of core. But that can be a followup issue.

(Saving credits for feedback on various past states of this issue and the previous discussion.)

Drush issue filed; adding it to the IS.

With #3265325: Raise a warning instead of an error when installing on MINIMUM_SUPPORTED_PHP this is now an installation/status warning rather than error, and we need to warn people that a sudden PHP requirement raise may be needed in case of dependencies changing and releasing security fixes. So this is the most graceful way we can nudge Drupal 9 users. My concerns were covered, IMHO looks good to land.

The change that was merged broke PHP 7.3 testing on 9.4.x - this showed up in postgres first as that is the only on commit PHP 7.3 we are currently doing. See https://www.drupal.org/pift-ci-job/2349026

Here's a patch-version of this to run with various environments. Slightly baffled as there are definitely no changes that should affect the database driver.

OK no, lol, this has a funny and obvious cause and has nothing to do with postgres, just our weird test default config and forgetting to just attach test runs the way I meant to in the first place. In my defense I got annoyed trying to find it at the to with the MR and went to bed. 😂

And the interdiff didn't upload. TLDR this is the problem:

diff --git a/core/install.php b/core/install.php
index ed2040260d..b8df4ae0dd 100644
--- a/core/install.php
+++ b/core/install.php
@@ -29,8 +29,8 @@
 // hardcoded minimum PHP version below (both in the version_compare() call and
 // in the printed message to the user) whenever \Drupal::MINIMUM_PHP is
 // updated.
-if (version_compare(PHP_VERSION, '7.4.0') < 0) {
-  print 'Your PHP installation is too old. Drupal requires at least PHP 7.4.0. See <a href="http://php.net/supported-versions.php">PHP\'s version support documentation</a> and the <a href="https://www.drupal.org/docs/system-requirements/php-requirements">Drupal PHP requirements</a> page for more information.';
+if (version_compare(PHP_VERSION, '7.3.0') < 0) {
+  print 'Your PHP installation is too old. Drupal requires at least PHP 7.3.0. See <a href="http://php.net/supported-versions.php">PHP\'s version support documentation</a> and the <a href="https://www.drupal.org/docs/system-requirements/php-requirements">Drupal PHP requirements</a> page for more information.';
   exit;
 }
 

That's the hunk in the core installer, which uses MINIMUM_PHP (not MINIMUM_SUPPORTED_PHP) and has nothing to do with this change. Of course it would pass as-is. The question is why we found that out from our PostgreSQL driver alone, and I am changing test environment config to avoid such confusions in the future.

Posted followup related to the string in #180: #3272275: Decide what to say very early in the installer if the site is below the absolute minimum

The distinction between MINIMUM_PHP and MINIMUM_SUPPORTED_PHP is tricky, thankfully there are good docs. But #178 vs #179 is clear enough :D