Bump minimum PHP for Drupal 9 to PHP 7.3

If we do this, then I think it would also make sense to remove PHPUnit 6 support.

@heddn sure a follow-up - was just wondering if it makes sense, since if this gets through than de-facto PHPUnit 6 will no longer be used for testing on DrupalCI (run-tests.sh upgrades PHPUnit to 7 when PHP is 7.3+ in HEAD already, in D8 as well as D9).

+1. The PHP 7.2 EOL is 30 November 2020, and is already out of active support. It makes sense to require 7.3 as the minimum for Drupal 9.

@heddn In #3103255: Add upper PHP constraint to composer.json and/or the installer, we desire that the PHP minimum version in the require element also be the same value that is written to the config.platform.php value. This means that the minimum version of PHP should not be 7.3.0, but rather should be the largest patch version of PHP required as the minimum PHP version of any of our dependencies.

If none of our dependencies require 7.3, then 7.3.0 is fine to use as the minimum.

@Charlie ChX Negyesi responded with a pointer to #2917655-43: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4 which was in comment to Drupal 8 raising requirements but some of it may still stand.

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.

Yes, thanks for raising that.

See https://github.com/symfony/symfony/issues/29459 with lots of pointers to serialize issues some of which are still open.

Besides BatchStorage there's https://www.drupal.org/project/drupal/issues/3011684 still open just for core.

I still believe it is doable by 2020 summer but we need to carefully search our issue queues for more serialize bug reports and make them release blockers.

Serialization is another challenge for 9.x so better to fix it early

I still believe it is doable by 2020 summer but we need to carefully search our issue queues for more serialize bug reports and make them release blockers.

Good idea. Anything that's a critical PHP 7.3 serialization bug would be a release blocker (or beta blocker, rather), but not non-critical ones.

This will probably need all the signoffs prior to commit. FWIW, I'm more and more +1 for this based on the data and discussion in #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4 and #2938725: [tracking issue] Track hosting provider support for PHP 7.

I think this would be a good should-have for the alpha as well, so adding it there.

@catch asked for product manager feedback. As a product manager I think doing this sooner than later is better because in alpha/beta we would get the bugs ironed out, versus doing it later would postpone the pain.

That said, if we make all PHP 7.3 blockers a blocker of beta (which in itself is IMHO a good idea), how does the still open Symfony issues reflect on our ability to release a beta in early March? I looked at the two open Symfony issues linked from https://github.com/symfony/symfony/issues/29459 (which itself was linked above):

• https://github.com/Lullabot/media_mpx/issues/147 - no action since 2019 July, does this still happen? Asked there.
• https://github.com/symfony/symfony/issues/34948 - not clearly explained but it sounds like the problem may be with custom code built on Symfony; also this has the "Unconfirmed" tag from Symfony folks for a month now; he also wrote at the same time I'm not sure anyone is experiencing the issue anymore.

In the single Drupal issue linked #3011684: Properly serialize \Drupal\Core\TempStore\PrivateTempStore the test only patch itself passes, so the problem is not reproduced currently.

To me these currently feel like a "there may or may not be something there", would need much more proof to block anything on them.

That said, if we make all PHP 7.3 blockers a blocker of beta (which in itself is IMHO a good idea)

I don't think this impacts the decision here very much, since PHP 7.3 will be the only supported PHP version in November this year anyway - i.e. even if we decided to support PHP 7.2 after all for some reason, PHP 7.3 support would still be critical (and also for Drupal 8.9).

However also unless we actually have core test failures or a reproducible critical bug, PHP version issues probably shouldn't block release milestones since we often don't have control over them if they require a fix to PHP itself (as some issues in dev versions of PHP have).

Thanks @heddn. The point is that if we require PHP 7.3. and there is a critical bug that does not happen on 7.2, that's in a way comparable to an upgrade path or other 9.0.x-only critical regression. Because in Drupal 8 you can stick with 7.2 but Drupal 9 forces you to update to 7.3, so there's a critical regression between versions. Again, this isn't just any bugs with the PHP version, just critical ones.

As another product manager, I would expect when making a decision like this, we would cross-reference PHP 7.3 support in the major Linux distros.

https://trends.builtwith.com/server for some reason lists IPv6 as an operating system (?!) but if you filter that out, it seems the most popular distros across the top 1m sites are Ubuntu, CentOS, and Debian (there might be better sources for this info; this is just one I happen to know). So we should check what version of PHP the latest stable + LTS version of each of those distros looks like.

Filed #3106918: Drop support of PHPUnit 6 in Drupal 9 because it will never get used anyway as a follow-up.

@webchick: we have been doing that discussion about distros (Ubuntu, Debian, etc) and impact in #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4 for months (including surveying Acquia partners and posting that at #2917655-54: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4, and data tracking at #2938725: [tracking issue] Track hosting provider support for PHP 7 for even longer :) Those are tracking/policy issues, so this is where the patch got posted.

Ok great, that was not at all clear from the issue summary but +1.

However also unless we actually have core test failures or a reproducible critical bug, PHP version issues probably shouldn't block release milestones since we often don't have control over them if they require a fix to PHP itself (as some issues in dev versions of PHP have).

Generally speaking, the serialize bugs are such that we have complete control over them.

Has it been considered that this will impact the ease with which sites can update from D8 to D9? Many D8 sites will run on PHP 7.2, currently. Even though the PHP project themselves do not support 7.2 from november onwards, security support is usually continued by OS vendors for some time, making PHP 7.2 still a viable alternative, from a hosting POV. (We've actually had pushback from the hoster when we told them our desire to update from PHP 7.0 because "it is supported by the OS vendor for years to come"; they have a completely different perspective).

Edit: Seems like this is all discussed in great detail over in #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4.

@eelkeblok: I see you found where its discussed :) The problem is not really operating system support.

Drupal depends on all kinds of PHP libraries. Those libraries have their own security processes and PHP support timelines. If one of them comes out with a security fix on their supported branch(es) and that fix is only available on code requiring PHP 7.3, then Drupal needs to raise its PHP version requirement in a matter of hours on a security release Wednesday. That would be definitely orders of magnitude more complicated for Drupal users as opposed to needing to run a higher PHP version from the get go with Drupal 9.

So we are attempting to raise PHP requirements as high as practically possible for Drupal 9 out of the gate, and may still need to raise it further before Drupal 9 goes end of life. Like we did with Drupal 8's PHP requirements, we'd rather raise in a pre-announced and planned fashion and not being forced to do it on a security release day. That however means we need to require a relatively high version from the start so we don't hit that bump too soon.

Makes sense. Thanks for the clarification. Does sound like "the other side of the coin", though :)

It is, there are trade-offs in both directions.

The big difference is that Drupal 8 users on PHP 7.2 have the entire 8.9.x support cycle to update to PHP 7.3 or higher (i.e. until December 2021), whereas someone who installed Drupal 9 with PHP 7.2 might have to update to PHP 7.3 within months or weeks if we dropped it in 9.1 or 9.2.

Let's do this then :) I left the other two types of core committer tags but Angie and I both support this as Drupal core product managers.

Both me and xjm have been +1 to this on the other issue, so removing 'needs release manager review' too.

After reading the linked issues (And linking a few more) as well as the symfony issue - and taking into account that we would make any critical bugs blockers, I'm comfortable removing the 'Needs FM review' tag.

Can we get a follow up to remove phpunit 6 support and shims?

@larowlan the followup is already open at #3106918: Drop support of PHPUnit 6 in Drupal 9 because it will never get used anyway (and we really should get #3063182: Remove PHPUnit 4.8 class aliasing BC layer in as well!)

Thanks, sorry

Re-rolled

Update core/INSTALL.txt file. PHP 7 ChangeLog.

--- a/core/INSTALL.txt
+++ b/core/INSTALL.txt
@@ -48,8 +48,8 @@ Drupal requires:
 - A web server with PHP support, for example:
   - Apache 2.0 (or greater) (http://httpd.apache.org/).
   - Nginx 1.1 (or greater) (http://nginx.com/).
-- PHP 7.0.8 (or greater) (http://php.net/). For better security support it is
-  recommended to update to at least 7.2.17.
+- PHP 7.3.0 (or greater) (http://php.net/). For better security support it is
+  recommended to update to at least 7.3.13.

Good catch!

Committed 9ed2caa and pushed to 9.0.x. Thanks!

I'm checking D9/D10 issues that are closed and tagged for change record updates. I have read the CR and it looks correct to me. REmoving tag.