[policy] Remove PHP 5.5, 5.6 support in Drupal 8.7

This makes sense overall, but I would recommend changing this:

1. When a version reaches official PHP EOL, we add a requirements warning.

2. When we decide to actually withdraw support, we'll announce it a full minor release ahead.

to this (changes emphasized):

1. When a version reaches official PHP EOL, we add a requirements info message.

2. When we decide to actually withdraw support, we'll announce it a full minor release ahead, and add a requirements warning as part of that release.

Fix backwards references to Drupal 6 and 7 in the issue summary.

In my opinion dropping support for a PHP major should require a major version number. Dropping support for a minor in a minor is ok. So PHP 7 as floor is Drupal 9, even if that means taking everything currently slated for 9 and moving it to 10, and releasing 9 with only that 1 difference in place.

@Aki Tendo, but we still support the previous major as well. So in that scenario, we would still have to support EOL PHP versions as long as the previous major was supported.

Drupal 6 had been out for 6 years when we dropped support for PHP 4. We did not drop support for PHP 4 by incrementing to Drupal 7; Drupal 7 was already out and already did not support PHP 4. But we could not continue to support a PHP version that was so far out of date for the old branch either.

According to #2864037: [META] Update core PHP dependencies we can't update 5/9 PHP libraries in the core due to PHP 5.5.9 as minimum version requirement.

This has been floating awhile now and it worries me: PHP 7.2's deprecate puts us in a bind. As can be seen in my proof of concept hack supporting PHP 5.x will require ugly version checks around every runtime assertion that is time consuming to run. Dropping PHP 5 support allows these version checks to omitted. Note that the version checks aren't *necessary* if we are willing to let PHP 5 users suffer further code slowdown -- about 2% for the cache tags alone in testing, possibly far more now that far more assertions are in the codebase.

There is really no good answer here, as long as e.g. we want to be compatible with http://packages.ubuntu.com/trusty/php5 until 2019

The real concern is an significant security fix in an old library version, but at some point maybe we should fiddle our composer.json to make it possible to build and install Drupal against php 5.5.9 (pulling in older library versions) but allow the official version to require 5.6?

IMO the choice has been made for us. Those are not mini obscure frameworks who upped the requirements. And we need them, or keep at old versions. Not saying we should always follow our dependencies, but those indicate to me a good reason.
I think we can for sure do an upgrade for those requirements, if we communicate clearly for example.
-We could announce now, that we're dropping for 8.5
-Warn inside 8.4 that php5.5 is not supported anymore (there's an issue for that).

In this case decide the same for php >= 7.0. As a policy say we can upgrade minimum requirements if needed for dependencies, but we'll anounce one version before. This would be a good compromise IMO.

Can someone do another research how hosters support different kind of PHP versions now?

-We could announce now, that we're dropping for 8.5
-Warn inside 8.4 that php5.5 is not supported anymore (there's an issue for that).

I agree, whatever change we make, we should have AT LEAST one minor version of time between it. Semantically we might want to jump to D9, but this is its own discussion.

Not sure about the full accuracy, but this page seems up to date.

https://webhostingcat.com/what-version-of-php-does-your-web-hosting-comp...

SiteGround 7.1.4
A2 Hosting 7.1
InMotion Hosting 7.1
GreenGeeks 7.1
Web Hosting Hub 7.1
Namecheap 7.1
iPage 7.1
HostGator 7.0
WP Engine 7.0
Bluehost 7.0
DreamHost 7.0
Media Temple 7.0
Arvixe 7.0
GoDaddy 5.6

And adding for relevance in drupal-land.
Acquia: 5.6 (7.0 according to their docs, seems not available for all yet) (https://docs.acquia.com/acquia-cloud/manage/php#php-version)
Pantheon: 7.0 https://pantheon.io/docs/php-versions/
Amazee.io: mentions php7 (https://docs.amazee.io/changelog.html#2016-04-26-php-56-and-php-70-3)
Platform.sh: 7.1: https://docs.platform.sh/languages/php.html

Seems safe in my opinion at first sight.

Related issue #2670966: Warn users of old PHP versions

Let's do it then.

Consensus? Is this moving too fast to RTBC? I don't think so, but I only read through the last month's comments. Is there strong resistance earlier?

Hmm, it probably is. Too many "needs review" tags from various manager groups. Back to review again :(

Quoting @xjm from #2831943-88: Use "rendered media" (not links) as default media field formatter; add modal to configure the used media view mode

a patch can still be marked RTBC if the only thing blocking it is a "Needs framework/release/product manager review" tag, since those are committer reviews

The information given in #18 and @catch suggestion in #17 I think we can RTBC this.

Updating issue summary, please confirm this is as per meeting discussion @catch and @xjm

I like most of what's in this proposal, but...

Under this proposal - php 5.5 support will be dropped in 8.5

I don't like this, because:

This means that whereas PHP core support for PHP 5.5 ended six months ago, Ubuntu will probably support it for a further two years.

Exactly. Ubuntu is one of the most popular server operating systems, so I don't think PHP 5.5 is really EOL until Ubuntu 14.04 is EOL, which is 2019. If Drupal 8.5 drops support for PHP 5.5 in 2018, then that's a year in which sites running on a stock Ubuntu 14.04 will be negatively impacted (either needing to hack core to continue running their site on 8.5+ or needing to stay on 8.4 and having to backport Drupal security fixes themselves). Although #18 is encouraging with respect to those hosting providers, it doesn't include all the organizations that commonly host internally (e.g., universities, etc.).

If there's an extremely compelling reason for Drupal to drop PHP 5.5 prior to 2019, then by all means, we should consider it. But right now, the only compelling reason identified in #2864037: [META] Update core PHP dependencies is Doctrine and Zend libraries. Note that Symfony 3.x continues to support PHP 5.5, and as far as I know, their BC policy is to continue supporting that in 3.x, and 3.4 won't EOL until 2021.

With regards to Zend, they used to provide LTS releases. I think we should try asking them for an LTS of 2.7 (the one we're on now and that still supports PHP 5.5). Alternatively, maybe we should consider downgrading to their 2.4 LTS and staying on it until Ubuntu 14.04 is EOL? Do we actually benefit from any of the improvements since 2.4 anyway?

Not sure what to do with Doctrine. In hindsight, I wonder if it was a mistake to use their libraries without them providing LTS releases. I don't know if they'd be open to providing LTSes going forward, and if not, I wonder if we should remove our dependency on them and instead write our own annotations parsing code.

maybe we should consider downgrading to their 2.4 LTS and staying on it until Ubuntu 14.04 is EOL?

Oops. That's not an option. LTS for 2.4 ends in March 2018, before Drupal 8.5 ships.

To sum up #24, my suggestion is to drop PHP 5.5 and 5.6 in Drupal 8.7 (after Ubuntu 14.04 EOL) and to drop 7.0 in Drupal 8.11 (after Ubuntu 16.04 EOL). And to remove dependencies on libraries that do not provide LTS releases that are compatible with the PHP versions we support.

And to remove dependencies on libraries that do not provide LTS releases that are compatible with the PHP versions we support.

That will be hard to achieve in practice. What if that impacts something like Doctrine or some other integral piece of functionality?

I feel that whatever warning action we take it should be "when active support for a PHP version ends" rather than "when a version reaches official PHP EOL".

I feel that whatever warning action we take it should be "when active support for a PHP version ends" rather than "when a version reaches official PHP EOL".

I agree @cilefen.

What if that impacts something like Doctrine or some other integral piece of functionality?

I don't think core's use of Doctrine is very integral. I think it's only for parsing annotations, and I think we can copy the part we need into a Drupal-namespaced class, and then own the security maintenance of it. Similarly for Zend: I think core only uses it for aggregator module, and we can probably take the parts needed for that into a Drupal-namespaced class. I guess we also use it for Simpletest, but I'd be fine with making Simpletest have a PHP 5.6 dependency, since that's not needed on production sites. But before removing core's production usages of Doctrine and Zend, I think it's worth reaching out to those projects to see if they're willing to provide a security-supported branch that retains PHP 5.5 support until Ubuntu 14.04's EOL. Surely we're not the only consumers of those libraries who care about Ubuntu users.

I see now that #2864037: [META] Update core PHP dependencies also lists symfony-cmf/routing as now having a PHP 5.6 requirement. It would be great to open an issue on that project to backtrack to the same PHP version requirement that Symfony 3 itself uses (5.5.9).

Another option is we keep using Doctrine, Zend, and symfony-cmf/routing, gamble on them not using too many PHP 5.6-only features, and ignore what their composer.json file says is their PHP requirement (i.e., we update DrupalCI to use composer's --ignore-platform-reqs option). And then when any of Drupal's tests fail on PHP 5.5, then we investigate the issue and subclass/override the problematic vendor code to work on PHP 5.5.

A strong NO to forking anything in core. We already have enough hard time fixing symfony sub-classes in core during symfony updates.

Seems like there is some good conversation going on again. Should this move back to NR?

In my experience upgrading Ubuntu 14.04 to use a newer version of PHP than it has out of the box should only be a concern if there isn't a supported newer version of PHP for that Ubuntu. A quick Google survey shows there's several upgrade paths out there. So to me, this feels like a misplaced concern.

The area of largest concern are the stock PHP offerings of the major vendors. GoDaddy seems to be the current floor with PHP 5.6. Users of these services often do not have the access permissions to upgrade PHP on the server, and even if they do they don't often have the expertise. Even if they do have the expertise, installing their own PHP on such a box voids some or all of their customer support contract and many users aren't willing to do that.

As for users who are running independent boxes, most have the technical chops necessary to upgrade their PHP. I'm willing to venture that the number of users who are running their own server and can't upgrade PHP are very low - and honestly it's a skill they need to learn if they want to continue going that route regardless of what Drupal does.

As for users who are running independent boxes, most have the technical chops necessary to upgrade their PHP.

They might be running multiple PHP applications on that box, including legacy ones that don't work on PHP 5.6 or 7.0. They might have organizational IT policy restrictions preventing them from installing a PHP build that doesn't come natively supported and patched by Ubuntu directly.

As far as I know, Drupal has never yet, in its history, put users of a widely available and still-security-supported version of PHP, into a situation of losing security support for their Drupal installation.

I was curious what other PHP CMSes are doing with respect to this. For the top 3 not counting Drupal:

• Wordpress: latest version supports PHP 5.2.
• Joomla: latest version supports PHP 5.3.
• Magento: 2.1.x requires PHP 5.6, but 2.0.x supports PHP 5.5 and is still security supported.

Until we put a call home feature into the admin panel to report PHP version in use we are all guessing.

There's always going to be outliers. I worked at an organization that insisted on using PHP 4 as recently as 4 years ago (I personally finally got them onto PHP 5.3 before I left). They're out there.

As long as we use outside components like Doctrine our floor will be controlled by them. If we want a floor lower than they support we'll have to ditch the offending components.

For what it's worth I question the wisdom of dropping support for PHP 5.5 for reasons already outlined. My prior post was more Devil's advocate than anything else.

We should not treat Ubuntu shipping with a version of PHP as "support" for that version. We're also adding a lot of work for ourselves to refactor and fork dependencies because we're unwilling to stop supporting versions of PHP that PHP has already stopped supporting.

As a reminder, this is the chart of version support on PHP.net:

The alpha of 8.4.0 has been delayed, and a bugfix for #2849674: Complex job in ViewExecutable::unserialize() causes data corruption reverted and delayed, because on Monday we had a high rate of segfaults on 5.6 due to a PHP bug that PHP has marked won't fix https://bugs.php.net/bug.php?id=72286 because PHP 7 is not affected and 5.6 has passed the end of active support. And that's 5.6, not 5.5. See the chart above. This has real impacts on Drupal.

The alpha of 8.4.0 has been delayed ... due to a PHP [5.6] bug

This issue summary's item #6 current proposal is:

• Drop PHP 5.5 in Drupal 8.5 (April 2018)
• Drop PHP 5.6 in Drupal 8.7 (April 2019)
• Drop PHP 7.0 in Drupal 8.7 (April 2019)
• Drop PHP 7.1 in Drupal 8.9 (April 2020)

In order to accommodate Ubuntu LTS, my counterproposal in #26 is:

• Drop PHP 5.5 in Drupal 8.7 (April 2019)
• Drop PHP 5.6 in Drupal 8.7 (April 2019)
• Drop PHP 7.0 in Drupal 8.11 (April 2020)
• Drop PHP 7.1 in Drupal 8.11 (April 2021)

The two proposals match for PHP 5.6, so do not differ in their impact on the issue mentioned in #38. Other than compatibility with Doctrine, Zend, and Symfony CMF routing, do we have examples where keeping PHP 5.5 support is hurting us, such as PHP 5.5 specific DrupalCI problems?

Looking forward to how we want to manage support for PHP 7.x minors, let's consider that Symfony 3.x reaches security EOL in November, 2021, so we'll need to security EOL Drupal 8 by then as well, which means release Drupal 10 by then. Assuming we want a minimum of 2 years between Drupal 9 and Drupal 10, that means release Drupal 9.0 by October 2019. Potentially we'll want a Drupal 9 sooner than then. For example, Symfony 4.0 comes out November 2017 (yep, right after Drupal 8.4 is released), so a Drupal 9 in April 2019 might be pretty sweet in terms of using Symfony's latest and greatest.

For Drupal 9, I think we should set the PHP minimum to whatever is the most recent version at that time. So whether that's April or October 2019, then that will be 7.3. Anyone stuck on an older PHP version can also stay on Drupal 8. So then my proposal of keeping PHP 7.0 and 7.1 supported in Drupal 8 a year longer than the issue summary's proposal only hinders us with respect to backporting fixes from Drupal 9. In other words, future DrupalCI problems we encounter with those versions in a couple years won't slow down the pace of Drupal 9 development, only the backports to Drupal 8.

We should not treat Ubuntu shipping with a version of PHP as "support" for that version.

It's not just that Ubuntu ships with that version. Ubuntu also security patches that version after PHP stops doing so, just as effectively as the PHP team does up until then. Ubuntu has an excellent history of doing that. And Drupal has always taken that into account, and we never communicated to people prior to them installing Drupal 8 that within Drupal 8's lifetime we will drop support for a PHP version that is still security supported by their OS vendor. If for Drupal 9 we want to communicate that our policy is to drop support when it reaches PHP EOL, and that we will no longer take Ubuntu LTS EOL into consideration, then that's fine, and people can factor that into their decision of whether to use Drupal 9 or not.

We're also adding a lot of work for ourselves to refactor and fork dependencies

If we're unable or unwilling to do this, then I guess we're forced into proceeding as the issue summary proposes, despite my unease with thinking it's an unfortunate thing to do to site owners on Ubuntu.

When we decide to actually withdraw support, we'll announce it a full minor release ahead.

Which means we have until October (8.4.0's release) to officially decide whether to drop PHP 5.5 support in 8.5 or not. What about sending an announcement saying that we will do so unless we get the situation with Zend, Doctrine, and Symfony CMF routing sorted out in the 8.5.x branch before October? It might be a longshot, but maybe if there are enough people who care about site owners on Ubuntu, they can help get those issues resolved in the next couple months?

Later this month I'm writing the patch to assertions to make sure PHP 7.2 doesn't throw deprecation notices. I was going to do this in a manner that preserves optimization for whatever PHP 5 versions are still supported. However, if we are dropping PHP 5.6 in a year and a half it starts to feel like double work.

So that raises the question, how much do we care about optimal PHP 5 performance now? Writing assertions with only PHP 7 in mind means PHP 5 always executes the assertion. There's no harm in doing this other than wasted CPU cycles, anywhere from a 2 to 5% loss of speed for PHP 5 installations.

Also, I don't want to write the patch and go through the approval process for it twice. I will if that's what the community wants since I created the mess, but I don't want to.

Other than compatibility with Doctrine, Zend, and Symfony CMF routing

Um, isn't this enough?

I would add phpunit to the list? Min on phpunit5 is PHP 5.6, and phpunit6 is PHP 7. Maybe not, though, but upping the PHP version would allow us to up the phpunit version.

Twig should definitely be in the list, though. twig2 required PHP 7.

Both of these are part of @catch's point about technical debt, feature roadmap, and our initiatives.

I have more I want to write in response to #42, but for now...

Or potentially update to Symfony 4 in a Drupal 8 minor release, if it doesn't require changes to Drupal's public API that are impossible to make.

I'm skeptical about this being possible to do in a way that keeps to the spirit of semver, or of http://buytaert.net/making-drupal-upgrades-easy-forever. Symfony's public API leaks into Drupal's public API all over the place. A couple examples:

• $request appears throughout Drupal's API and code. In Drupal 8.0 - 8.3, calling $request->isMethodSafe() with no arguments was considered the canonical, API-recommended, way of determining whether the request method is safe, and various core modules invoked it. That is now deprecated in Symfony 3 and throws an exception in Symfony 4. Therefore, any custom/contrib Drupal 8 modules written in the last 2 years that used this API will break in a Drupal minor release that updates to Symfony 4.
• Symfony\Component\Validator\Constraints\Choice has a public property $strict that got deprecated in 3.2 and is removed in 4.0. Drupal's AllowedValuesConstraint extends this class, and therefore inherits this public property, which is settable through the $options parameter of Drupal\Core\TypedData\DataDefinitionInterface::addConstraint().

I'm sure there are dozens of other examples.

Our own technical debt and feature roadmap...should be determining our major release schedule.. not the release schedules of third-party libraries we happen to depend on

I think for third-party libraries that don't leak so much into Drupal's APIs, that's true. But Symfony's role in Drupal's API is more extensive and special. I think it would be better for Drupal module authors and Drupal site owners for Drupal's major release schedule to eventually sync up to Symfony's. For example, for Drupal 10.0 to be on top of Symfony 6.0, Drupal 11.0 to be on top of Symfony 7.0, etc., with the Drupal release being the one that follows the Symfony one by a few months to a year, depending on how much time we need to incorporate it. Drupal 9 is the special one though, because we still have a lot to do in #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1, but for Drupal 10 and later, I don't see why we'd need or want to deviate from Symfony's cadence.

Keep in mind that every PHP requirement bump will annoy a certain portion of hosting providers and users. To minimize that annoyance, we should not be deprecating 5.5 and 5.6 separately. Thus, effulgentsia's #39 makes more sense.

If I had to choose, I'd stop supporting 5.5 and 5.6 in Drupal 8.6 (October 2018).
That's two minor releases and a full year away. Gives us two-three DrupalCons and Driesnotes to warn people about it. It doesn't cover the entirety of Ubuntu's 14.04 LTS window, but it's more than enough, considering we'll have 16.04 and 18.04 at that point. Two LTS releases are enough, support-wise.

If I had to choose, I'd stop supporting 5.5 and 5.6 in Drupal 8.6 (October 2018).

I like the idea of this, because it gives a full year notice about it, assuming we make an official announcement by October 2017. I like the idea of a full year notice, because different organizations have different months/quarters for planning their yearly work. For example, a university might want to plan their IT upgrades to happen in the summer, and summer occurs at different times of the year in different parts of the world.

Regarding 5.6 though, that would be before its official EOL. I think we should either drop 5.6 in 8.7 (April 2019), or if we drop it in 8.6, could we make a special provision to keep providing security support for 8.6 for an additional 3 months to cover the PHP 5.6 lifetime? We can discuss that idea more here, but at some point, if we're serious about it, we'd need to get approval for it from the security team.

It doesn't cover the entirety of Ubuntu's 14.04 LTS window, but it's more than enough

I've come around to agreeing with this. I think a year of notice that Drupal sites on Ubuntu 14.04 need to either install a later PHP version or upgrade to Ubuntu 16.04 is sufficiently reasonable. If they decide to plan their upgrade between July 2018 and October 2018, then they can potentially go straight to Ubuntu 18.04, but that's just a bonus for those lucky ones.

Looking forward to how we want to manage support for PHP 7.x minors

Before considering 7.0, let's first consider 7.2 and beyond. Since Ubuntu 18.04 isn't out yet, we have the opportunity to set a policy that we can communicate to people prior to it arriving, and thereby give new users deciding on whether to use Drupal or not an opportunity to plan accordingly. Let's assume that 18.04 will contain PHP 7.2. The issue summary currently proposes to drop support for PHP 7.2 in Drupal 8.11 (April 2021). But upgrading from Ubuntu 18.04 to Ubuntu 20.04 won't be supported until July 2020, so that means users will only have 9 months to do so instead of a full year. What would you all think of either waiting until 8.12 (October 2021) to drop 7.2, or else continue to security support Drupal 8.11 for an extra 3 months, to give Ubuntu users a full year to upgrade? If people here think it would be better to not do this and just stick to this issue's current proposal, then I guess that's ok, since we'd at least be communicating the situation to people prior to them installing Drupal on 18.04.

For 7.0, I kind of think the same thing, but more strongly. We should either support it until Drupal 8.8 (October 2019) or else security support Drupal 8.7 until July 2019, in order to give Ubuntu 16.04 users a full year to upgrade to 18.04. But I think we should do this even if we choose not to offer this extension for 7.2 and beyond, because there are already existing users of 16.04. However, I do want to acknowledge that there's a particular challenge with 7.0 in that Zend Framework 3 has a PHP 7.1 minimum and ZF2 will lose support by January 2019, and per #24, we're still using a few of their components.

I completely rewrote the issue summary. Please fix or improve further as necessary.

This issue is for "decide and document", and that needs to happen by 8.4's release (if we want to give people the notice that is proposed in the proposed resolution's options), so setting the version to that.

Assigning to @Dries, because all of the options presented will still result in some hardship to existing Drupal users. He should make the final decision on that. This is still open for discussion and feedback in the meantime though.

I prefer option 1 but given it is unlikely to get support, +1 for option 3, despite being more work, it is best of both worlds

i change my vote, +1 for option in 52 :)

Just a note but composer generally wants PHP 7.1+

So a lot of messages I deal with are people saying what is wrong how do they fix it With composer pushing people towards 7.1+ now it might be simpler to align requires against composer suggestions. I know a lot of people won't like this idea but the fact is we put up with a lot of bad practices from hosts and as Drupal stops accept bad standards it should consider for PHP to possible copy composer for PHP recommended version.

Just a point and my thought on it.

@ikit-claw - There is an issue #2843328: Enforce minimum PHP version in composer dependencies which is looking at composer. You can add a platform version to composer.json then composer will only load libraries compatible with that version no matter what you have installed locally. I assume you always see PHP 7.1 packages because that's what you have installed locally.

@catch wrote:

This would be following the same timeline as option 1, but apart from from hook_requirements() warnings, we don't do anything to actually stop Drupal 8 working on PHP 5.5 until Ubuntu 18.04 is released.

What about performance degrading changes? Putting all the assertions on a non-eval format would incur a performance loss for PHP 5.x but everything would continue to work normally, just slower than now.

@ikit-claw Yes, a lot of people won't like the idea 🙁.

@cilefen a good chunk of modules now require composer, not because they need to but because the creators couldn't be bothered to write docs for a manual install. Times that by the effort required for distributions and composer is a logical solution, I wish people would allow an alternative but alas it is quicker to use composer so that is what is happening.

8.5.0 is targeted for March, not April. Correcting this in the summary.

When Ubuntu 18.04 LTS is released, add the PHP 5.6 requirement to the development branch and allow dependency updates.

What does this mean? Updating DRUPAL_MINIMUM_PHP? Something in the composer configuration? Both?

#38 is really helpful, but I think adding drupal versions makes it easier. (I really just wanted to play with the svg generation used on that page, so hopefully this is helpful, I just copied over the release dates of 8.3 and 8.4 to the next years for dates).

I really like @bojanz's arguments in #39 about removing 5.x support in one swoop - but that doesn't seem to be one of the options in the IS (that are really hard to understand). In any case - we really should make some decision before 8.5 is tagged to make this not have to wait another 6 months.

#65 that sounds great. Since 7.0 is also EOL by then, we should probably drop support for it at the same time as well?

We discussed this during a committer meeting with Dries at DrupalCon Vienna, with most of the committers present (sorry, I don't remember anymore who wasn't present). We basically agreed to #46 / #65. Therefore, I'm removing the "Needs * review" tags, and unassigning from @Dries.

Since 7.0 is also EOL by then, we should probably drop support for it at the same time as well?

We decided against this. Partially because 7.0 is the version in Ubuntu 16.04 and 18.04 isn't even out yet. And partially because we think it's cleaner to make a break from PHP 5 first, and work out our process for dropping 7.x minors in a followup issue and in later releases.

I've updated the issue summary's Proposed Resolution with a draft announcement. Please help with reviewing it so that we can post it soon. The draft announcement text still needs reviews, so isn't RTBC, but I believe the policy decision to be RTBC, so setting the status to that, partially also to raise its visibility. I'm also raising the priority to Critical, since running on unsupported library versions exposes us to increasing levels of security risk. Any one of them, on their own, probably wouldn't merit a Critical priority, but the growing set eventually crosses a threshold, and we need to get this announcement out well before we cross it.

Added a section to the announcement about this not affecting Drupal 7.

I read through the announcement and found it comprehensive and useful. The only issue I found with it was that some sentences could be broken up to make it easier to read. Apart from this, I was wondering if we should link to some alternative community solutions to host Drupal on Docker.

The announcement is great. I agree with @hussainweb with making it easier to read; I put it in a google doc to propose edits:
https://docs.google.com/document/d/1kQG4E2L6Ye-M0RUuz7UkTZfyUPKoI-Vd2s8Y...

We've had SOAP requests break in PHP7 keeping clients on 5.6 until the API has REST or we can get time to fix. Something about the SoapVars malforming.

Granted 8.6 is a year away, it's part of legacy and maintenance only mode code. So there needs to be a lot of messaging if this happens. Otherwise was unlikely consequences.

It looks like this decision has been finalized aside from the exact wording of the announcement? I am dismayed by this -- aside from a tweet by larowlan a few days ago, I didn't know this discussion was even taking place (issue open for 8 months, but who can follow all the issues?), and I feel like the community of Drupal 8 users has been left out of the process for this really fairly major decision.

Why do I think this is a major decision? Because removing support for PHP 5.6 in D8 will affect me in fairly annoying if not downright negative ways. The reason is that I'm not just running Drupal 8. On my local development computer, I am currently running everything from Drupal 6 (yes, really) to Drupal 8, several versions, plus WordPress and some stand-alone PHP scripts. I use them for various purposes, including needing to temporarily run earlier versions in order to port them to D8 (there are many still out there), and for other things. On the shared hosting service where I host my own web sites, I have 2 D7, 2 D8, and 1 WordPress site, all in the same shared hosting account (and thus on the same server).

I think probably on my local site I can figure out how to have two versions of PHP running at the same time for different areas of my local dev server (I believe this is possible but don't look forward to figuring it out).

But I doubt I can even do that on my shared hosting. I *think* they have PHP 7 available as an option, but I don't think they let you run two versions of PHP at the same time for different URLs (not sure). Will D7 (and all contrib modules I use in my D7 sites) run successfully under PHP 7? What about WordPress? I am not sure. I don't really want to be put in a position of dumping sites, or moving to another web hosting service, or doubling my hosting budget by splitting into "compatible with PHP7" and "compatible with PHP 5.6".

So it's not just Drupal Core version 8 that you have to think about. This impact on real users of Drupal 8 is not in the issue summary -- I didn't read through all the discussion, but it seems like it hasn't been thought about. So... I think this decision should be discussed further with the larger community before it is down to "RTBC except for small wording changes". I doubt I am the only person who will be adversely affected by it.

I think @jhodgdon raises a valid point regarding shared hosting.

Whilst we cannot support every combination, we should give consideration to at least supporting both versions that we support here, namely Drupal 7 & 8.

For Wordpress and Drupal 6, I think that is out of our control.

For Drupal 7 on PHP7 we have this meta #2656548: Fully support PHP 7.0 in Drupal 7 which currently has one remaining child issue #2756297: element_children sort order inconsistent between PHP 5 and PHP 7 [Drupal 7 backport], in the meta @klausi notes that he's been running D7 on PHP7 in production for 12 months+ with only that child issue remaining a problem.

So I think part of this announcement should be that we aim to have PHP7 supported on Drupal 7 in time for the release of 8.6. Which would mean we should aim to have it ready as early as possible to allow people to test - and report any issues that may arise in contrib.

Does that sound like a worthy addendum to the policy/announcement?

I note that PHP7 support for Drupal 7 is already tagged as 7.60 release target (Drupal 7 bumps into the next series of 10 when new features are released, e.g 7.50 included features that 7.4x did not)

Regarding PHP7 support for Drupal 7, what about contrib modules? Just having Core support PHP 7 is not enough if there are problems with compatibility in contrib modules -- unlike in 8, you really cannot run a 7 site that does anything at all without quite a number of contrib modules. ... I personally am unfamiliar with all the differences between PHP versions, but I know that when I updated Ubuntu the last time and PHP7 was the default, I quickly had to uninstall that and go back to 5.6 so that I could get everything on my local site running. I don't remember exactly which things didn't work...

And one more thought: expecting contrib module maintainers to support PHP 7 and/or test compatibility for their D7 versions is probably unrealistic. Most module maintainers are not really actively doing development on their D7 versions, I think? I know for the ones I support, I'm sometimes doing bug fixes if they're really major, and would of course address security questions, but... we are all busy people.

Again, I don't really know what the "gottchas" are. The D7 PHP7 support issue seems to have about 10-15 child/related issues, so I would guess it's not trivial for contrib modules to support PHP7 either?

So realistically, Drupal 7 is going to be supported well after PHP 5.6 is EOL. In fact PHP 7.0 will be end of life before Drupal 9 comes out.

So I don't think it is unreasonable for contrib authors to patch Drupal 7 versions to add PHP 7 support - I'm not saying they should write the support, but I'm saying that if someone provides a patch, we'd expect they'd be happy to apply it.

But key to that, is getting Drupal 7 core to support PHP7 sooner rather than later, so we have as much time as possible between now and Sep 2018 to get those contrib patches written.

Personally I support many Drupal 7 sites and I would love for them to move to PHP 7, even for the performance gains alone.

We should reach out to the three Drupal 7 maintainers and make sure they're on board with this. It could even be a new initiative. Yes - an initiative for Drupal 7!

As this will leave people with unsupported installations should Drupal 8.6 be called Drupal 9.0?

Otherwise people who for whatever reason cannot upgrade past the last 8.5.x will not get security support while Drupal 7.x will still have it.

As this will leave people with unsupported installations should Drupal 8.6 be called Drupal 9.0?

Otherwise people who for whatever reason cannot upgrade past the last 8.5.x will not get security support while Drupal 7.x will still have it

Releasing 9.0 means EOL for 7.x. I don't think we want that.

With Drupal 8.6, Drupal 8 will be (almost) 3 years old already.. I think Drupal 9 could be an option after 3 years of Drupal 8.

No matter what we call the release that drops PHP compatibility, there is no doubt that we are forced to do so, by both PHP itself and our external dependencies. I think we'll need a drupal.org announcement that explains this in detail.

And one more thought: expecting contrib module maintainers to support PHP 7 and/or test compatibility for their D7 versions is probably unrealistic.

As is expecting contrib to support 5 PHP branches at once (5.5, 5.6, 7.0, 7.1, 7.2 with 7.3 around the corner in a year). Anyone who installs a site with next year's Ubuntu LTS will get 7.2, so this is not an unrealistic scenario. Considering all of that, D7 contrib not working on PHP7 should already be an ecosystem-level critical problem. Supporting PHP5 beyond the grave won't solve that.
TL;DR: The only reasonable solution is cutting PHP5 support and organizing a community effort to ensure all of D7 runs on PHP7.

Releasing 9.0 means EOL for 7.x. I don't think we want that.

That would be a funny joke. We still have no complete working migration path from D6 to D8 and a totally incomplete D7 to D8 migration. Next major Drupal version should have a new rule. If migration is not final and 100% working - a major must not released. What happened here in near past with D8 is really a mess and must not happen again.

I agree with @bojanz in that there are external factors in driving PHP 7.x adoption and dropping support for PHP 5.x. I realise that it is not easy for local installs and shared hosting but there are some alternatives there to make the process a bit easier. We should document those in the announcement. I think that is important because realistically, we have to drop support at some time and I think it is better we do it before PHP itself drops support.

I think that Drupal 9 discussion is just a tangent to this discussion. I seem to recollect a discussion that dropping support for PHP versions does not count as an API break, and hence is possible in Drupal 8.x cycle itself.

Having said all this, I +1 on @jhodgdon's suggestion to promote this discussion to the wider community.

I think that Drupal 9 discussion is just a tangent to this discussion. I seem to recollect a discussion that dropping support for PHP versions does not count as an API break, and hence is possible in Drupal 8.x cycle itself.

Yeah, with Drupal 6, we dropped support for PHP 4 before the EOL with this announcement:
https://groups.drupal.org/node/390343
Following this discussion over the course of a few months before that:
https://www.drupal.org/node/2140113

That was announced 3 months ahead of time; with D8 and PHP 5, we're increasing it to a year. Admittedly though that decision didn't have the complication of having to support PHP 4 for D5 at the same time, since D5 was already several years past its EOL. So we definitely want to have as much advance notice as possible without causing serious maintenance issues for D8, and it's worth using he next year to make sure D7 runs on PHP 7.

Regarding the questions about Drupal 7, we already announced that Drupal 7 core supports PHP 7 back in July 2016 (as part of the Drupal 7.50 release), and in practice I think it worked before that also since the fixes in that release were mostly just about test failures. I've commented a couple times since then that #2656548: Fully support PHP 7.0 in Drupal 7 could just be closed since there's nothing left to do there, but I haven't pushed too hard for it since that's basically a meta issue that could be used to coordinate fixes for contrib also. Speaking of contrib, presumably there are some PHP 7 bugs out there, but for the most part it seems to work well since anecdotally people have reported switching Drupal 7 sites with many contrib modules over to PHP 7 and not running into any problems.

All that said, I agree with many of the concerns jhodgdon raised. This issue proposes cutting off support for PHP 5.6 before even the PHP project cuts off support, which is an extremely aggressive timeline. (When Drupal 6 dropped support for PHP 4, that happened years afterwards, and furthermore, nothing was directly done to prevent sites from using it - in fact, I think it's entirely possible that the final release of Drupal 6 core still actually worked on PHP 4 in the end.) Overall, there is a risk that this move will feed the perception that Drupal 8 is still "in flux" and not ready for use on production sites.

It would probably make sense to encourage contrib module maintainers to shift their automatic tests on DrupalCI to using PHP 7 instead of PHP 5.6, for those contrib modules that have automated tests. I'm not sure how best to get the word out -- perhaps a separate announcement or an email message sent out to all module maintainers, or all that have opted in to automated testing?

This issue proposes cutting off support for PHP 5.6 before even the PHP project cuts off support, which is an extremely aggressive timeline.

Would it make a meaningful difference to anyone here if we provide security support for Drupal 8.5 for an additional few months in order to get past the PHP 5.6 EOL? In other words, release Drupal 8.6 in September, 2018, but continue security supporting Drupal 8.5 until December 31, 2018, which is PHP 5.6's EOL?

My own opinion is that this would have little actual benefit in practice, since there's no Ubuntu LTS version with PHP 5.6 as the default, and shared hosting companies have already had a lot of time to switch to PHP 7, so I don't know that an extra couple months will make a difference to them. But if you think it's crucial to do this, I can inquire into whether the security team would be willing to take on the extra work for those few months.

I think that is important because realistically, we have to drop support at some time and I think it is better we do it before PHP itself drops support.

I'm strongly against this. In past I was not able to upgrade my vserver 2 years after EOL. However I tried to update Drupal. There are also linux distributions that support PHP after PHP EOL. I think discontinue support 2 years after EOL is a good time and no earlier. The absolute minimum should be 1 year after PHP EOL.

For #90, I'd rather just drop support in 8.7.x instead in that case (probably for both PHP 5.5 and PHP 5.6.). Dropping support in the middle of a minor release would create more work than it would save.

Edit: I meant in 8.7.x, sorry. Fixed.

Bumping the dropping of 5.5 and 5.6 to Drupal 8.7 would have the advantage of getting us past both the Ubuntu-php-5.5 EOL (April 2019) and the PHP 5.6 EOL (December 2018). That's a win for people who want to wait until a PHP version is already security vulnerable prior to upgrading.

However, it would mean that we'd be stuck on old and no longer security supported vendor library versions for an extra minor cycle. Meaning, instead of starting to upgrade them in 2-3 months (when 8.6 branch opens for development), we'd push that to 8-9 months from now (when 8.7 branch opens for development). Seems to me like that's both inconveniencing developers/maintainers and potentially exposing the vast majority of Drupal users to some security risk (if one of the unsupported vendor libraries ends up disclosing a security exploit) in order to accommodate a small minority of Drupal users in their desire to procrastinate the inevitable. It's possible that's the right choice, but I'd like the people asking for that to really consider if that's truly what they think is best.

Seems to me like that's both inconveniencing developers/maintainers and potentially exposing the vast majority of Drupal users to some security risk (if one of the unsupported vendor libraries ends up disclosing a security exploit) in order to accommodate a small minority of Drupal users in their desire to procrastinate the inevitable.

That's unfair and borders on mean. It's not procrastination and laziness but economics. The clients that freelancers tend to have don't appreciate security problems and it can be very difficult to convince them to pay to fix something that, to them, isn't broken. More often than not they have to bite the bullet and do the upgrade server wide, where the server is used for multiple clients, without any pay from any particular client.

So, they have their reasons for resisting upgrades and they are reasonable ones. I wish I could think up a solution for them, but I can't think of any past "stop upgrading and pray."

Looking at some trendlines...

https://w3techs.com/technologies/history_details/pl-php/all/q
https://w3techs.com/technologies/history_details/pl-php/5/q

... pushing the date back a few months probably won't make a big difference. PHP 5 usage is likely to still be high then either way.

Pushing it back a few years (e.g. to match Symfony, which the issue summary says won't drop PHP 5 until 2021) would be a different story.

The only way to follow Symfony's lead and continue to support PHP 5 until 2021 is to drop our use of libraries that don't support PHP 5. Doctrine's annotation is one of them off the top of my head. That is likely too massive an undertaking to be feasible.

These are not always economic reasons. There are hosters that do not provide up to date installation images.

I do not see a reason to show a stop sign and block upgrades of Drupal just because a php version is EOL. If there are serious drupal bugs fixed, that only work in newer PHP versions - than ok. But there is typically no need to prevent an update of drupal. There could be a drupal security update and if I get pushed back and cannot install it - my site runs drupalgeddon and I cannot stop it just because you lock the upgrade. Maybe only because a non-used minor module does not support any longer my outdated php version. That is really not ok.

If there is no absolute need to block a php version we should not do it. This does not mean we officially support it. But do not add barriers for no good reasons, please.

That's unfair and borders on mean. It's not procrastination and laziness but economics. The clients that freelancers tend to have don't appreciate security problems and it can be very difficult to convince them to pay to fix something that, to them, isn't broken. More often than not they have to bite the bullet and do the upgrade server wide, where the server is used for multiple clients, without any pay from any particular client.

I'm in this situation. I maintain a server that has around 30 Drupal 7 sites on it. Having to update PHP versions is something that is part of the work that is required when maintaining a server. Last year in July PHP 5.5 was EOL so I had to update to PHP 5.6. In 2 months time PHP 5.6 will be EOL and I will update the server to PHP 7.0.

None of my clients pay me to upgrade their websites to PHP 7.0. But they do pay me a monthly fee to host their websites, and this is just part of the work. I also update all the other software on the server on a weekly basis. These updates are paid for by the monthly fees and the increased workload needed for a PHP upgrade is offset by the several months a year that do not have any significant work required.

tldr; If you are hosting client sites in a responsible way you should take care of software updates and this should be included in your rate.

I think we should not use any unsupported vendor libraries in core because of potential security issues. If our vendors upgrade to PHP 7, so should we.

Re #96 well at least in the instance of doctrine annotations the problem is going to be shared because Symfony 3 depends on it too.

One big difference between Symfony's approach to dependencies and Drupal's is that they don't ship with a composer.lock file and lock everyone that uses Symfony onto specific versions of their dependencies. This is an advantage of only supporting install via Composer I guess. They also run tests with their highest and lowest dependencies as allowed by their composer.json file. Life is a bit simpler when you are only shipping a framework and not an application which includes all of its dependencies. Not including the dependencies makes you less responsible for the security of the said dependencies.

I think that because Drupal includes its dependencies in a tarball and ships with a composer.lock file we are responsible for the security of our dependencies. We have to ship a Drupal with currently security supported code (if such a thing exists for a dependency - and if it does not I'm not sure we should be depending on it).

Given that some of our dependencies are leaving security support for PHP 5.x behind, it feels like we have three choices:

1. depend on the libraries with security cover (which will in effect match our own PHP version constraints with theirs)
2. fork the library and make it part of Drupal's responsibility to keep up to date
3. remove the dependency altogether.

I think the second and third options will turn out to be extremely expensive for Drupal maintenance. But it might be worth going through each of our dependencies and consider the three choices.

• symfony\*: Has been discussed a lot above - Symfony 3 will be PHP5 compat - so not an issue unless we move to Symfony 4.
• Twig: 2.x is PHP7 only. We're on 1.x which will support PHP5.x as long as it is supported - I've not found any information for when support for 1.x will be dropped. If 1.x security support is dropped we would have to move to 2.x because as this is our templating layer and security is paramount.
• doctrine\*: No LTS release - we're already on unsupported versions - the versions the are supported have already dropped PHP5.5 support and will drop 5.6 very soon. This dependency makes me ponder the "remove the dependency altogether" - we have filed PRs against Doctrine and they don't want to consider them because they want to drop support for the static annotation parser altogether. If they did that we'll need to rewrite it because our plugin discovery depends on being able to determine what annotations a class has without actually loading the code as callable PHP.
• guzzlehttp/guzzle: Looking at https://github.com/guzzle/guzzle#version-guidance we're likely to have PHP5.5 support with Guzzle for a while - but there are no certainties as there Guzzle makes no statements about when v6 will be EOL'd
• symfony-cmf/routing: We want to deprecate this but still the latest version is not PHP5.5 compatible. But even if we deprecate this it would be hard to completely remove the dependencies. That said, given what we actually use of this dependency the security issues are extremely low risk.
• easyrdf/easyrdf: Supports 5.3 and doesn't seem to be moving very fast - Looking at https://github.com/njh/easyrdf is not even tested on PHP 7.x and there is a bug on PHP7.1 that means it'll throw warnings. Fortunately not for something that Drupal core uses.
• zendframework/zend-feed: I think this is the dependency that has the biggest risks of not moving. Zend Feed is handling external data and parsing it for use in our application. That means that being behind on security updates and not having support is extremely risky. One thing that is extremely tricky is that we seem to have a proliferation of services in core.services.yml using Zend feed classes and there's #2919215: Deprecate feed.bridge.writer. That said we are definitely using the feed reading services.
• stack/builder: This is an extremely small dependency - 2 classes that have not changed in the last 3 years! Supports 5.3 - again no promises on continued support but the whole point of this dependency is interop so it is super likely to be conservative.
• egulias/email-validator: We're not on the latest version there's no info about security support or long term support. The latest version is 5.x compat. This is aligned quite closely with the Symfony world so I'd expect it to follow their lead.
• masterminds/html5: The next version is PHP5.x compat at the moment. There is no release information about security cycles and long term releases.
• zendframework/zend-diactoros: has the same issues as zend-feed - perhaps less risky because of what it is doing but still.
• composer/semver: very low risk because this is only used in \Drupal\Core\Composer\Composer - our scripts that run during a composer install. However this does make me ponder what promises Composer is making for PHP5.x compatibility. A cursory look on the internet didn't reveal anything.
• paragonie/random_compat: This a PHP5.x polyfill for PHP7 in-built methods - it's whole reason to exist is PHP5.x support - if we drop PHP5.x support we should remove the dependency.
• asm89/stack-cors: Current supports >=5.5.9. The project makes no promises about security releases and long term support. As this handles the request any security issues here would be extremely important to address.

So as pointed out by many above, the real issues with our dependencies come right now from doctrine and zend. And using the three choices laid above - I think we could make a reasonable argument that it might be in our interest to remove our dependency on doctrine given they want to remove functionality we need. But Zend is far more challenging - it's libraries are handling untrusted input for us and any security there could be serious and not being able to run we the latest security release is very problematic. We can't remove the Zend dependency without replacing both the libraries we depend on. One option with Zend is move to their LTS release (2.4.x) which would get us to 2018-03-31 see https://framework.zend.com/long-term-support - this would mean downgrading but at least we'd be on a security supported release. Which we are not ATM.

But let's say for arguments sake that we do the work to remove or get support for doctrine\* and zend\* we are still at the mercy of our other dependencies. If Twig 1.x support is dropped we would have to drop PHP5.x immediately. Many of the other dependencies don't pose this kind of risk but the same applies. And the moment any of them drop 5.x we'd potentially have to do masses of work.

One potential option could be to remove composer.lock from Drupal core and test against our highest and lowest dependencies ala Symfony. That way if you want to use a PHP5 version of Drupal 8 you'd be responsible for installing and managing the dependencies. Then we could have a tarball project that fixes the dependencies for building the tarball and is the recommended "product". This would drop PHP5 support because it is shipping with fixed versions of our dependencies that have to be security supported. However, doing something like this would be a lot of work and incur a lot of additional costs and result in a lot of change that will be disruptive (for example to DrupalCI). For me the big issue with doing something like that is that the users most likely to need to PHP5.x support are the tarball users and the tarball won't support it. So for me, this solution is also not worth the effort.

tldr; I think if we want to continue to support PHP5.x till the Symfony end date of 2021 then we need to get commitments from all of our dependencies to do the same. I think this will take a lot work to achieve and might not even be possible since someone maintaining a dependency can always say "no" - (i'd expect doctrine to do that - although the Symfony dependency on it makes that interesting). So I think we have no choice but to stop supporting PHP5 in either 8.6 or 8.7.

An aside about PHP7.0

Re PHP7.0 and #67

We decided against this. Partially because 7.0 is the version in Ubuntu 16.04 and 18.04 isn't even out yet. And partially because we think it's cleaner to make a break from PHP 5 first, and work out our process for dropping 7.x minors in a followup issue and in later releases.

One of the ironies is that latest versions of Doctrine have also dropped 7.0 so if we are doing this to have supported versions of our dependencies even after removing PHP5.x support we still won't be on a supported version of Doctrine. (Aside I think we should reach out to Doctrine to clarify if any of their releases to have LTS - I think they are going to have to because of Symfony's dependency on them).

Given that some of our dependencies are leaving security support for PHP 5.x behind, it feels like we have three choices:

1. depend on the libraries with security cover (which will in effect match our own PHP version constraints with theirs)
2. fork the library and make it part of Drupal's responsibility to keep up to date
3. remove the dependency altogether.

I think something similar to option #2 has been done in the past, going back several Drupal major versions (at least Drupal 6 and probably earlier). Don't update the library if doing so will break things, but if a security issue is reported, patch or monkey-patch it to fix the problem.

It's worth keeping in mind that these dependencies are generally just "libraries" -- compared to Drupal which has a user interface -- and therefore there are fewer types of security vulnerabilities they are likely to have, and even when they do it is often more of a "security hardening" issue than a direct vulnerability. As an example, the jQuery fix in https://www.drupal.org/SA-CORE-2013-001 was arguably just security hardening (but it did make sense to fix the API anyway, rather than trying to track down every piece of vulnerable calling code).

I think for Drupal 8's biggest dependencies like Symfony (and probably Twig, maybe Guzzle) those are probably too large to try to take security responsibility for. But for the smaller ones that have a much more limited purpose, it doesn't seem that different to me than in the past (although there obviously are more of them in Drupal 8). So the list in #99 is definitely very interesting to look at.

So I asked Doctrine about security support for versions prior to the ones that require PHP7.1 - https://github.com/doctrine/doctrine2/issues/6799

@ocramius, the maintainer of Doctrine wrote:

We fix security issues as far back as we can, so that's not a problem.

We don't do bug LTS support.

zendframework/zend-feed: I think this is the dependency that has the biggest risks of not moving. Zend Feed is handling external data and parsing it for use in our application. That means that being behind on security updates and not having support is extremely risky.

My read of Zend's announcement is that on January 1, 2019 (3-4 months after Drupal 8.6 is released), Zend Feed will not be security supported on PHP 5.6 or on 7.0. Unless someone can point out how I'm reading that wrong, or knows of any other information about LTS versions of any Zend components.

Re: #99 -

One big difference between Symfony's approach to dependencies and Drupal's is that they don't ship with a composer.lock file and lock everyone that uses Symfony onto specific versions of their dependencies. This is an advantage of only supporting install via Composer I guess. They also run tests with their highest and lowest dependencies as allowed by their composer.json file.

See: #2874198: Create and run dependency regression tests for core and https://github.com/paul-m/drupal_dependency_bounds_test

We should also be doing this specifically for our components anyway. See: https://github.com/paul-m/drupal_component_tester

doctrine\*: No LTS release - we're already on unsupported versions - the versions the are supported have already dropped PHP5.5 support and will drop 5.6 very soon. This dependency makes me ponder the "remove the dependency altogether" - we have filed PRs against Doctrine and they don't want to consider them because they want to drop support for the static annotation parser altogether. If they did that we'll need to rewrite it because our plugin discovery depends on being able to determine what annotations a class has without actually loading the code as callable PHP.

The first baby steps on that: #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core

Doctrine's position seems unreasonable to me.

PHPUnit is similarly aggressive. PHPUnit 4, the last version to support PHP 5.5, is no longer supported. PHPUnit 5, the last version to support PHP 5.6, will become no longer supported on February 2, 2018 (almost a full year before PHP 5.6's EOL). While this isn't as bad as with Doctrine, since PHPUnit is not needed on production, it's still pretty bad for us, since I don't think that we can meaningfully provide Drupal support for Drupal code that we can't test.

Running an older version of PHPUnit is also less of a security risk since it can be (and should be) disabled entirely in production anyway.

Just to point out that D8 isn't actually compatible with PHP 5.5.9: #2919410: Drupal 8 is not compatible with PHP 5.5.9

Setting this back to NR since there is ongoing discussion.

Doctrine is only required for tests, but not for production systems, isn't it? So we only need to block the upgrade if the "Tests" module is enabled. There are no other issues without, so - who cares except developers. We should add a php 5.6 requirement to Tests module .info file and that's it. The rest of core is still compatible with 5.5.

That is like every contrib module that defines a phpo requirement. Now a Drupal Core module should also add this requirement, but this does not mean complete core is unusable with php 5.5. We just need to check every module, not just core and push back only because one of 50 modules is not compatible with 5.5

Aside - can Drupal update module collect the used php versions to d.o so we know what versions are really used in the wild?

@hass
Just to correct you, we use doctrine to scan for our plugins so we use it basically everywhere.

Aside - can Drupal update module collect the used php versions to d.o so we know what versions are really used in the wild?

This is an interesting question!

A call home module has merit, but for privacy reasons it needs an opt-out.

Maybe some useful information to make a decision. PHP 5.5 is now at 6% usage and PHP 5.6 at 23% for composer users.

https://seld.be/notes/php-versions-stats-2017-2-edition

We should though take into account that composer users at this point in time are probably not the majority of Drupal users.

I'm not certain it matters. Supporting 5.5 is a security issue waiting to happen... 5.6 is 13 months until no more security support, which is actually about a month longer than PHP 7... I don't know what all needs to happen in order to move us to 7.1, but it seems like we should be seriously considering it. That gets us security until Dec 2019.

Reference: http://php.net/supported-versions.php

Eclipse

I updated the title to reflect the reality of security supported PHP versions in the next year.

Eclipse

I worked with several enterprise which own their own IT. And each time, I have to fight to have the latest PHP version on their production server. After two years, From end of 2014 to 2016, I succeed to make them switch from PHP 5.3/RedHat 5 on PHP 5.6/Debian 8.

Their argument was that their old PHP version was supported by their support contract.

I do not pretend that this is representative, but each time I have to work with enterprise (administration, big company) , I met some old PHP version. There is even a week, I intervened on a site (Drupal 7) that was still on PHP 5.3 for a large company known in France.

I do not know how the companies that have gone on Drupal 8 will handle that, but it will certainly be disruptive, as they say ...

Had this problem too, but most of the time, the argument that switches them to agree is /not/ that is is twice as fast, but that it enables them to get the same performance on smaller, cheaper servers.

I thought the issues with 7.2 had been rolled back by the php team. :-(

So what's policy on issues adopting 5.6+ syntax then? I have a new feature issue with two sides wanting certain functionality, and if I could use variadics and argument unpacking, I could make both sides happy.

Should I have this conversation someone other than this issue?

Eclipse

RTBC + 1

Note that announcing this doesn't necessarily mean we'll prevent people upgrading on PHP 5.5 or PHP 5.6 in 8.6.x , we can still decide when to allow PHP7-specific syntax in core and even if we prevent installation, it won't stop upgrades without failing on purpose.

Probably it's best to allow PHP7-specific syntax to be used right away. Not saying that we should immediately start using it in every new patch, but we should not set any false expectations that the whole Drupal ecosystem will continue working on PHP 5.6 after 8.6 .0 is released.

Since we announce our minimum PHP version in composer.json and we are using Composer to build the release tarballs, Composer can start picking up PHP 7 based dependencies at any point. It might be that 8.6.0 still works fine on 5.6, but maybe 8.6.2 won't. Composer won't prevent PHP7 dependencies from being used if they comply with our minimum requirements.

Which PHP 7.0 version is core going to support?

@jibran Let's discus that at #2832838: Wrong recommended PHP version for Drupal 7

@catch:

Note that announcing this doesn't necessarily mean we'll prevent people upgrading on PHP 5.5 or PHP 5.6 in 8.6.x , we can still decide when to allow PHP7-specific syntax in core and even if we prevent installation, it won't stop upgrades without failing on purpose.

I do not trust you on this. Once a minor 8.x comes out you stop support of previous D8 minor versions. If you discontinue PHP version tooo early we may need to keep an older branch up-to-date with security fixes only for all who CANNOT upgrade. An Drupal 8.5 LTS version for older PHP versions with 2-5 years security only fixes post PHP EOL date.

> If you discontinue PHP version tooo early we may need to keep an older branch up-to-date with security fixes only for all who CANNOT upgrade.

But those people will be running unsupported, possibly insecure PHP. They'll be running unsupported, possibly insecure versions of all of Drupal's dependencies, which we can't do anything about. Providing security fixes for Drupal with this is like locking your front door when all the windows are open.

@Joachim

100% agreed. PHP has changed, and we need to adapt. That's why I tossed 7 under the bus too earlier in this thread because by the time we discontinue support for 5.5, both 5.6 and 7.0 will also no longer be getting security releases. A clear move to 7.1 sends the message that Drupal is really on board with this whole PHP thing, and that we take the security of our platform as seriously as the code we ship. I'm super happy to see this issue moving forward. We need to acknowledge that gone are the days of us supporting hosts who don't stay up to date, and PHP is updating often now.

Eclipse

@hass The Drupal community has been put in a bit of a bind here - we either keep up with the accelerating PHP ecosystem, or get left behind. Ceasing support isn't being done out of spite and believe me when I say, if there was a better compromise solution it would be implemented. Unfortunately the closest thing to that is to designate 8.5 as a LTS release and then continue issuing patches for it even as development continues on 8.6, 8.7, and so on. To do that though resources would have to be allocated to backporting patches to vendor libraries we don't normally patch or even touch the code of.

One of the points of Drupal 8 was to leverage code from other ecosystems, and modifying that code, even for security patches, runs counter to that. The resources of the community are limited since this is a volunteer project, and the resources of the security team which would have to apply these patches is even more so. It's just not feasible to do it.

Also, as pointed out by Eclipse, there's really no security patch we could issue in order to patch exploits in PHP itself. Now, granted, the Ubuntu Linux project and others backport patches for EOL PHP's even after the PHP project themselves do, but they have the resources to do that. We don't.

There are several linux distros that will backport security bugfixes a lot longer than php EOL date. I do not believe on this 3rd party library issues need to happen and are automatically a drupalgeddon. If there is an issue in a newer 3rd party lib it may be possible to backport, too. Mostly these fixes are a few lines maximum.

I fully agree that it is bad practice to run unsupported software, but this is not automatically insecure. Dropping support without having a single idea how many percent are using a php version is wrong. We cannot drop support if there are 25% on php 5.6 and people *cannot* upgrade! Than the 3rd party libs need to step back, accept the 25% and extend support timeframe until it drops to 1%.

That is the same sh** like D6 support. Migration suite is not ready, but D6 support stopped. What should people do??? I understand that they keep insecure D6 software running.

@hass,

We, as a community, helped to push forward into PHP5. Today we are dragging to not leave? It's not a matter of just backporting code from one version to another. Yes that's an aspect of it, but it is an over-simplification. The second I introduce variadic syntax into Drupal 8, no one running 5.5 will be able to upgrade Drupal 8 without upgrading their PHP. There may not be a tolerable solution to "backport" that code. The second I introduce scalar typehints, the code will only work in PHP 7. There's not a backport for that... anonymous classes... probably not a good backport for that... etc, etc. Some of our dependencies have already moved to minimum version of 7.1 (as I keep saying is the sanest step to take). We adopted dependencies because it was less code to maintain... you want us then to expend resources forking and maintaining that code because some hosts aren't moving? We've proven once before that we can be a force for moving hosts from one version of PHP to the next. We are only proposing it is time to do it again. And that this is likely to become a more frequent (not less) event. To that end, hosts will upgrade, or they'll die. Simple as that. Let's not fight to stay on lower version of PHP, let's adopt new version, benefit from new features, and help to push everyone forward together. WAY WAY better than being stuck on old code that won't do what we need.

Eclipse

We can break compatibility with a major version, but not with a minor. Otherwise we need minor versions with LTS support. This means not 6 months after next major. Keep in mind that D6 support stopped 6 monts after release of D8. When was migration ready? Ahhh we are at 8.4 and it is still not ready... 2 years later. D7 to D8 upgrade? Impossible, too. Nothing works. Maybe I can upgrade D7 when we reach D10? That may be 5 years after php eol? If we need to talk about priorities, we need to make sure an upgrade path REALLY exists before breaking compatibility.

Really think you're overstating it. I've done D6 and 7 migrations at this point with relatively minor (but agreed aggravating) issues. I also don't see how Drupal 6 has anything to do with ensuring that D8 is not running on old php versions.

Eclipse

I also don't see how Drupal 6 has anything to do with ensuring that D8 is not running on old php versions.

Shared hosting on one server. Both a Drupal 6 and a Drupal 8 site are on same machine, and for whatever reason multiple PHP runtimes can't be setup on the same machine. Hence the PHP version in use must work with all the Drupals on the machine.

@hass

All those points are valid, but they don't address the driving issue - the resources to do a LTS minor don't exist. It might be possible if we were only talking about Drupal community code, but the driving force here is the libraries we are using - particularly Doctrine.

We can break compatibility with a major version, but not with a minor. Otherwise we need minor versions with LTS support.

Drupal 8.4.x (and currently 8.5.x-dev) uses the Symfony 3.2.x library. Symfony has an LTS policy which says that their 3.4.x library will have LTS status. It says that 3.4.x will have end of maintenance in 11/2020 and EOL in 11/2021.

Currently, symfony/http-foundation 3.4.x-dev says this in its composer.json: php: ^5.5.9|>=7.0.8

This means that, as long as this PHP version requirement is true for all components we use, and is continued for all patch versions of 3.4.x, we could make a LTS Drupal which tracks it.

We currently have an issue about upgrading to newer symfony versions: #2874909: Update Symfony components to 3.3.* (a critical) ...and I thought there was one about 3.4, but I can't find it.

So if the plan is to have D 8.5.x use symfony 3.4.x, then 8.5 can be LTS as far as that's concerned.

That leaves Zend and Doctrine. #2864037: [META] Update core PHP dependencies illustrates that we would need at least PHP 5.6 for some version bump there, and I think it's reasonable to say that a Drupal LTS should only supports PHP as low as 5.6.

So: 8.5.x should remove support for PHP 5.5, and use Symfony 3.4 plus other dependency versions bumps this allows. Then that would be supported as LTS until D9.1.

8.6.x would then only be PHP 7+ (or 7.1, depending on what's decided here).

So here's a patch. I updated versions as per the versions in #2864037: [META] Update core PHP dependencies and then ran composer update using PHP 5.6.10. Obviously the tests fail because we're not yet supporting these versions of symfony components, but Composer is happy. There are probably better low version constraints than the outdated ones from that other issue, but this illustrates that some of this is possible.

What technical issues would prevent us from having this policy?

I specify technical issues, because there are probably other valid issues, such as finite maintainership resources. I'd be interested in hearing those, too.

The second I introduce scalar typehints, the code will only work in PHP 7. There's not a backport for that... anonymous classes... probably not a good backport for that... etc, etc.

Really, you need to wait with such breaking changes until D9. This cannot done in minor versions or I may misunderstood what semantic versions are made for.

I expect that D8 will work with the php versions it started with. I cannot tell a customer to re-develop a website every 6-12 months. Just because some people break their system with a security update I cannot step away from. You guys should really rething what semantic versioning means and what changes are allowed in minor versions.

You may better name 8.5 => 9.0. but than make sure the migration module is ready and D8 is still maintained for an extended time.

I only complain as I see the same type of breaks happen again and the real life situations seems to be ignored and most users left behind with old drupal versions with no upgrade path. There are also modules in use that are still not compatible with php7 just to name one more example - and you talk about php71 and php72. This will destroy drupal mid term as nobody will spend money anymore on smaller / medium drupal projects as they look tooo challenging and expensive and drupal development is not the only thing people need to do.

Semantic versioning is defining the public API of the project, then not introducing breaks to that public API. It says nothing about PHP versions unless a project includes that in their definition of public API, which we deliberately don't.

Why has Google Analytics and Piwik been broken at mid 8.x if the D8 API is stable e.g #2790371: \Drupal::entityTypeManager() silently disappeared and #2856231: Replace deprecated uses where \Drupal::entityManager()->getTranslationFromContext($node) disapeared? I'm highly interrested why this public api has been broken. Stable API is something different.

@hass

\Drupal::entityManager()->getTranslationFromContext() has never stopped working.
\Drupal::entityTypeManager()->getTranslationFromContext() has never existed.

If you're going to complain about off-topic matters, it'd be great if you get your facts straight first!

\Drupal::entityManager()->getTranslationFromContext() has never stopped working.
\Drupal::entityTypeManager()->getTranslationFromContext() has never existed.

(To expand on this, the ::getTranslationFromContext is in entity.repository, not entity.type_manager. The non-deprecated way to access the function statically is Drupal::service('entity.repository')->getTranslationFromContext().)

@tim: everything has existed and worked. I tested and verified it myself. It worked for sure before and never caused warnings/errors and is no longer working as it has been in 8.0. Use previous ga releases with previous core editions. Than upgrade core to 8.2 or 8.3 and you will see it breaking. You need multilingual site and enable the feature to see the errors.

OT for sure, it only shows my developer expierience of last few years. Several compatibility breaks and no upgrade paths. Totally unacceptable. And now with every minor D8.x the previous .x becomes unsupported. Great if I cannot update.

@hass, the relevant error in google_analytics appears to have been added in #2712415: Deprecated Method on Apr 24 in an attempt to fix deprecated usage (entityManager() should have been replaced with service('entity.repository') rather than entityTypeManager()), but was only released in 8.x-2.1 on Aug 9, which would explain why it was not reported until Aug 28.

I have tested this, and found out that 8.x-2.0 does indeed work on both 8.1.9 and 8.2.8, while 8.x-2.1 produces the reported error on both. =)

If we maintain PHP 5.5 support, we're going to end up on unsupported versions of all our PHP dependencies, and have to backport security fixes for them. This has been stated several times in this issue, but you've not addressed it.

See my comment in #100 which addresses that.

Importantly, for the forseeable future this does not involve all of Drupal's PHP dependencies, or even close to it. From reading this issue, and in particular #99 and #101, it seems like there is one real "probably" (Zend) and a few "maybes". And one that everyone thought would be a problem (Doctrine) looks like it won't be, once someone reached out and actually asked them about security support in #101.

Given that, I think this issue is really in a "needs more info" status more than anything else.

We, as a community, helped to push forward into PHP5. Today we are dragging to not leave?

The first release of Drupal that required PHP 5 was Drupal 7.0, which came out in January 2011. That's around two-and-a-half years after the PHP project dropped support for PHP 4 (see http://php.net/eol.php).

Since PHP 5 support will end in late 2018, two-and-a-half years after that would be 2021, which would be consistent with Drupal 8 waiting to drop PHP 5 support until Symfony does. But the plan that has been marked RTBC in this issue (despite many people not agreeing with it) is much more aggressive than that.

And of course that doesn't even consider the fact that Drupal 7.0 was a major release, so people who weren't ready to update could just stay on Drupal 6. This issue proposes doing it in a minor release, which is very different.

To be honest, I would hold up the long time it took to adopt PHP5 (seven years from PHP 5.0.0 to Drupal 7.0.0) as a bad example that we do not need to emulate anymore, especially considering that PHP7 is less BC-breaking than PHP5 (see register_globals, pass-by-value objects) was.

We need to consider not just how many years beyond EOL Drupal can provide free first-class support for old PHP versions (to the point of forking its dependencies, even), but also what that support costs in terms of being unable to take advantage of PHP7's DX and performance-improving features. The cost will also grow as we increasingly get stuck on outdated dependencies - if not today (see PHPunit), then definitely a year from now.

Drupal 8 passed D6 usage barely a year ago, which isn't a lot of time to built inertia. On the other hand, legacy support for PHP5 will become increasingly expensive as our dependencies adopt PHP7. Postponing it until Drupal 9 (and therefore until we are ready to drop D7) simply does not seem feasible...

Since PHP 5 support will end in late 2018, two-and-a-half years after that would be 2021

That would mean supporting 5.5, 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5 at the same time (assuming a yearly PHP release cycle continues). 8 branches.

I'd honestly be fine with just releasing Drupal 9.0 instead of 8.7 in April 2019, dropping 5.5, 5.6, 7.0 at once.
But I know that going to 9 is going to be a marketing and politically driven decision due to how people perceived the 8.0 upgrade.

But no matter how we formulate it, we'll reach 2019 without PHP5 support. Even if contrib needs to lead the way.

I'd honestly be fine with just releasing Drupal 9.0 instead of 8.7 in April 2019, dropping 5.5, 5.6, 7.0 at once.
But I know that going to 9 is going to be a marketing and politically driven decision due to how people perceived the 8.0 upgrade.

Well, aside from the D7 drop, a major release is the only window for removing deprecated and BC layer code. That's a much bigger break than PHP7+, and it's something we definitely don't want to do often - so releasing what would be D8.7 as "D9" isn't just a matter of naming, but also means freezing the API again until D10. (And in the long term, it seems disproportionate to break the entire contrib ecosystem by incrementing our own major version every time we so much as raise the minimum minor version of PHP 7.)

> (And in the long term, it seems disproportionate to break the entire contrib ecosystem by incrementing our own major version every time we so much as raise the minimum minor version of PHP 7.)

Oh yes, good point.

And that means that we definitely need to be dropping support for older versions of PHP with minor version changes. PHP releasing their own versions on a yearly cycle forces that.

I mean, we could freeze our minor version dependency of PHP for years at a time and then jump 2-3 versions at once. But this would be quite painful to develop for.

(I guess this whole discussion is a philosophical disagreement between traditional monolithic systems - where a single PHP interpreter and webserver runs all sites, sometimes on shared hosts with many different users - and more modern containers, in which all aspects of the system are isolated, defined per-project and easily changeable. The needs of these two kinds of environments are hard to reconcile.)

@David_Rothstein,

Per your comments in #100, I think most of us are suggesting that we don't want to do any version of option 2. Forking dependencies has all sorts of ramifications, and needs to account for the fact that the vast majority of us are not experts with those libraries. Could I (or many of us) trouble shoot things in Doctrine or Symfony? Yeah probably, but that's not the same as having ocramius or fabpot reviewing a problem and accepting a fix (or fixing it themselves). Obviously we COULD do this, but I don't think we SHOULD do this.

Also, as others have already pointed out, I don't think that Drupal 7's development cycle (as compared to our community's efforts to get PHP 5 adopted) is a thing to repeat. My point was that we have helped to push PHP adoption forward in the past, we should acknowledge that we have influence in this regard and commit ourselves to using it going forward. PHP development has changed. With the new release cycle PHP itself has adopted, we, as a PHP project, need to adapt and adopt new strategies, not double down on old one and be part of holding PHP back.

Eclipse

@catch makes sense to start notify users with 8.5 release about moving to php7, I agree with EclipseGc that like Drupal was involved in "goPHP5"

Maybe better to promote php 7.1 instead of 7.0 in #2670966: Warn users of old PHP versions

Before we promote PHP71 the test bot need to get fixed. See #2918251: PHP 7.1.4: JSON seems to have a bug with floats where nobody answers for more than 1 month. Maybe Drupal.org also has issues upgrading to a fixed PHP71 version?

break the entire contrib ecosystem by incrementing our own major version

I do not understand this statement. The use of deprecated functions in Drupal core, in your custom code or in contrib modules is a bug which needs to be fixed after every minor core release. The only supported version of Drupal 8 currently is the 8.4 release.
So in case everyone is fixing their bugs, the deprecated functions, then removing the BC layer will not do any harm to anyone.

Porting modules from Drupal 8 to Drupal 9 would mean to change core: '8.x' to 9.x in info.yml file (and fixing the deprecated functions introduced in latest Drupal 8 minor).
https://dri.es/making-drupal-upgrades-easy-forever

The use of deprecated functions in Drupal core, in your custom code or in contrib modules is a bug which needs to be fixed after every minor core release.

This isn't going to happen in practice - letting modules move to new minor versions on their own schedule is one of the reasons for maintaining backward compatibility in the first place. So you could be running a Drupal site on 8.7 and be using modules that were last released for anything from 8.0 to 8.7. This allows the contrib ecosystem to continue to grow.

By contrast, a major version change (even assuming 9.0.0 is fully backward compatible with 8.final.x minus deprecations) hits the reset button on that ecosystem. You can't upgrade until every module you use gets ported. No matter how easy the 8.final->9.0 upgrade is, it'll take a long time for all modules to actually get ported.

Regarding #160, in a way that's true, but it's also the case that the only thing someone needs to do to port a module to 9.x is remove all the deprecated things, which they can do once the preparation of the 9.x branch is announced if not before, versus rewriting everything through a churning trial-and-error of "Now what's broken".

So while working on #2670966: Warn users of old PHP versions I had a thought.

Dropping support for the old versions doesn't need to initially prevent you from updating Drupal; that might have the opposite effect of what we want by making people run old PHP and stay on insecure versions of Drupal itself.

We can make it an error during runtime and installation, but only a warning on the update phase, that says something like:

Your version of PHP is no longer covered by PHP's security support policy and no longer supported by Drupal. Future Drupal releases may no longer work on this PHP version. You should update your PHP version as soon as possible.

They can bypass an update warning and still run their updates. However, we stop going out of our way to support PHP 5.5 and 5.6, but we also don't immediately introduce any PHP 7 syntax that would cause fatal errors on 5.6. If people start getting errors or can't resolve their composer dependencies anymore, tough -- they chose to ignore our warning.

So you're suggesting that we tell everyone we only support 7 for a while before we actually only support 7? I mean, that's great, but we should do that before 8.6 imo (or whatever version we're adopting 7.1 support for). Introducing just one variadic patch makes us ACTUALLY dependent on 5.6+ (a language feature that would have been quite useful on a number of occasions already). Just saying that if we're actually making the move in a particular version, people are going to start writing patches to adopt the new language features, and I think that's a good thing, but I'd hate to see confusion over WHEN that's happening because we signal it before it's actually true.

Eclipse

I'd tend to agree - by all means, warn about it in the UI (as early as 8.5.0) when running on old version, but let's minimize confusion about what "unsupported" and "may no longer work" mean. As long as we keep it in the CI tests, it should definitely work (and is therefore technically supported), and once we use syntax features, it definitely won't. :)

Something like "Your current version of PHP will not be able to run Drupal 8.6.0, which is expected to be released late 2018" would set clearer expectations and a fixed deadline.

We're also going to do #164 as soon as possible anyway; #162 is unrelated to that. Also, please don't bikeshed the text of #162 just yet. ;) It's just an example and we can discuss that in a dedicated issue when I branch 8.6.x. :)

I'm trying to close the gap between core contributors who legitimately don't want Drupal to take on the support burden of dependencies or to support old and potentially insecure PHP versions, and other contributors and Drupal users who also legitimately raise concerns about dropping support too abruptly, hosting multiple Drupal versions, Ubuntu LTSes, PHP 5.6 still accounting for a significant percentage of installs, etc. The fact is, you're both right.

We, as core developers, are not going to support PHP 7 after we drop support; If 8.6.0 is the version that officially ends support, you will not be able to install 8.6.x on PHP 5 and it will break eventually. But for existing, production sites, someone having a fatal on some odd page is a less severe problem than not being able to apply a security update.

What I'd probably do is:

1. Configure a PHP 5.6/MySQL nightly for the 8.6.x branch.
2. Configure only PHP 7 test environments for 8.7.x.
3. Wontfix PHP 5-only bugs following the release of 8.6.0.
4. If something broke PHP 5, I'd probably just revert the commit from 8.6.x only. I'd leave the commit in 8.7.x and mark the issue fixed (which we already do for various bugfixes that might be disruptive to backport). That way, there's no extra work or maintenance burden, but we also don't needlessly break stuff nor punish PHP 5 users in a patch release.
5. If a critical bugfix broke PHP 5, well, we can cross that bridge when we come to it.
6. We could raise the update warning to an error in a later release.
7. Separately, work on removing our Doctrine dependency before then, as there are a number of other reasons to do this. (See also #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core.)

The point is that, as a release manager, I need to reconcile several legitimate, competing release management concerns raised in this issue, and this is a way to do that.

4. If something broke PHP 5, I'd probably just revert the commit from 8.6.x only. I'd leave the commit in 8.7.x and mark the issue fixed (which we already do for various bugfixes that might be disruptive to backport). That way, there's no extra work or maintenance burden, but we also don't needlessly break stuff nor punish PHP 5 users in a patch release.

I guess #165.4 also implies that new features in 8.7.x can use the new PHP7-only syntax features like scalar typehints and variadics since it wouldn't be backported.

I guess #165.4 also implies that new features in 8.7.x can use the new PHP7-only syntax features like scalar typehints and variadics since it wouldn't be backported.

Yeah, that was my thinking. It means that if 8.6.0 is the release that ends support, we'd still have to support PHP 5 during the 8.6.x development phase, but since things backported to 8.5.x would need to have PHP 5 syntax, we'd be doing that already anyway. But in that scenario, 8.7.x would be free from those constraints and 8.6.0-rc1 would be the point at which developers could move forward to PHP 7, without having to worry about language differences between the branches. Then, we could run a one-time test against RC1 of each minor, and upgrade the warning to an error when something sufficiently important actually appears to be broken.

I absolutely agree that we need set the date and start warning people about it as soon as possible in any case, so that people can plan. A year is enough time for an organization to move Drupal 8 to appropriate hosting, upgrade a PHP version, or put legacy applications that might break on a different server.

"if 8.6.0 is the release that ends support, we'd still have to support PHP 5 during the 8.6.x development phase" : not sure I'm following this reasoning. How is it different from after 8.6.0-rc1 ?

Is it only to make backports to 8.5 simpler, or is there some other reason ? 8.6@dev is not supposed to maintain the rules of 8.5, but align to the target 8.6 rules, is it ?

@fgm, 80% of all core fixes are backported to the production branch. This means that while the production branch supports PHP 5, 80% of issues must have a version of the fix that works on PHP 5, and so trying to add PHP 7 things to the development branch while the production branch supports PHP 5 just means extra work for ourselves. So if 8.6.x will introduce the requirement for PHP 7, we still should continue to test it against PHP 5 until RC to avoid issues when we try to backport fixes. Then, after RC, both branches move forward. 8.6.x becomes the production branch and requires PHP 7 for new installations. We commit whatever we want to Drupal 7, and then just don't backport things that break on the old PHP nightly.

We should keep php5 compatibility until 8.7 and not break in 8.6-rc1. Often PHP support has been extended short before it ended. It should be kept as long as possible and not break the earliest possible with a stupid eol date argument - most have no problem with as some linux distributions support a lot longer.

Aside, we still have no statistics about usage. Collect this first, than discuss next steps, but not before.

Php people always communicated too early eol dates or they have just been ignored.

@xjm: thanks for the explanation. So it's really about simplifying backports; I was wondering whether there was something else I'd been missing.

What if, instead of relying on statistics from others, we change update.module to somehow report the php version back to drupal.org? Are we allowed to do that?

Then we could actually get an idea of what PHP versions *drupal* sites are using and how many are still on PHP 5.

Well, speaking of statistics from others: https://seld.be/notes/php-versions-stats-2017-2-edition shows the breakdown for the population of Composer users. Obviously, there are Drupal 8 site owners who don't use Composer on their web servers, so these numbers aren't as valuable as if we collected PHP version stats in update.module.

[Edit: sorry, I wrote that prior to seeing #113].

#2927806: Use PHPUnit 6 for testing when PHP version >= 7.2 is highlighting another problem with supporting lots of PHP versions - PHPUnit is very quick to drop PHP version support. We are going to have lots of headaches testing on both PHP7.2 and PHP5.5.

Based on the feedback on this issue, we've decided to make the end-of-life for our PHP 5 support happen in Drupal 8.7 rather than 8.6. This places our EOL after PHP's official end of 5.6 security coverage rather than before (and also is around the time that Ubuntu's last LTS with PHP 5 is EOL). The official end-of-life for Drupal 8's support of PHP 5 is March 6, 2019, with the release of Drupal 8.7.0.

All currently supported PHP versions will be tested during the 8.7.x development phase prior to 8.7.0, since PHP 5.5 must be supported for Drupal 8.6 backports.

Starting with Drupal 8.7.0 on March 6, 2019:

• New sites will not be able to install on PHP 5.5 or 5.6.
• An error will appear on the status report for sites on PHP 5.5 and 5.6.
• Sites on PHP 5 will still be able to run Drupal updates, but a warning will be presented on the update screen.
• The 8.8.x branch will not be tested against PHP 5.
• We will update to PHPUnit 6.
• If possible, the 8.7.x branch will have one nightly test against PHP 5.6 (with PHPUnit 4).
• If a commit breaks the 8.7 nightly test on PHP 5.6, it may be reverted, but site owners should expect bugs and fatal errors if they do not update to PHP 7.

We're going to rewrite the previous announcement draft based on this information:
https://docs.google.com/document/d/1kQG4E2L6Ye-M0RUuz7UkTZfyUPKoI-Vd2s8Y...

However, we will address this as part of #2927344: Specifically warn about end dates for PHP support for old versions and this policy issue is now closed.

Thanks everyone for the feedback on this important decision!

We forgot a CR. Added one here: https://www.drupal.org/node/2938726