[policy] Require PHP 5.5

I think there is a very important distinction between "Drupal 8 requires php 5.4" vs "Drupal 8 requires at least php 5.4"

I don't believe that it is necessary to require php 5.5 unless we really need to leverage new features that 5.5 provides.

Im of the opinion that if we should target 5.4, with the constraint that we also build with forwards compatibility in mind, and therefore allow that D8 will *also* run on 5.5 and 5.6 without problems.

We need merely ensure that we don't use anything that will be deprecated:
http://www.php.net/manual/en/migration55.deprecated.php
http://www.php.net/manual/en/migration56.deprecated.php

And make sure that if we are using a function that is going to change between versions, that our use of that function is compatible:
http://www.php.net/manual/en/migration55.changed-functions.php
http://www.php.net/manual/en/migration56.changed-functions.php

There really doesn't seem to be too much backwards incompatibility like we had with the jump between 5.3 to 5.4.

webchick brought this up on irc - posting here.

We also have the option of dropping PHP 5.4 support after 8.x is released. Drupal 8.4.0 released in 2016 or something could require PHP 5.5.

We did this with PHP4 with https://www.drupal.org/node/2159315 more or less because PHP4 support kept getting broken all the time anyway.

I updated the issue summary with updated information on CentOS, Fedora, Bluehost, and HostGator.

updated GreenGeeks PHP Versions.

Opened #2301501: [policy, no patch] Explicitly decide and document that mininum requirements for major versions might get raised in minor versions.

updated opesSUSE

Dries confirmed on #2301501: [policy, no patch] Explicitly decide and document that mininum requirements for major versions might get raised in minor versions that we'll raise the PHP requirement after release if we have a good reason, so that means we can revisit this whenever it becomes necessary, not just before release candidate.

#2395443: [policy, no patch] Follow symfony 2.7 or 3.0., this is the question may mean a PHP 5.5 requirement for 8.1.x or 8.2.x.

Bump - all security fixes for 5.4 will end this September: http://php.net/supported-versions.php

Bump - all security fixes for 5.4 will end this September: http://php.net/supported-versions.php

That is a very strong argument to update the minimum requirements to PHP 5.5 now. Even if we would release 8.0.0-RC1 today, by the time 8.0.0 comes out there will be little or no time left before PHP 5.4 is EOL.

Moving to PHP 5.5 would allow both core and contrib to benefit from the great new additions to PHP 5.5, such as "try-catch-finally" and being able to use expressions inside of empty(). A very big benefit of PHP 5.5 is also that it has an opcode cache built in.

+1.

We already said we'd bump the requirement to 5.5 in Drupal 8.1 for Symfony 3, might as well do it now if we're going to release when PHP 5.4 goes EOL.
There's not a big argument feature-wise, but there is one philosophy-wise (big projects like Drupal should never encourage the use of discontinued PHP versions).

EDIT: Aside from the opcache, an obvious benefit is the simplification of #1845004: Replace custom password hashing library with PHP password_hash().

Totally +1

Debian jessie should be out later this month and will ship with at least 5.6.7.

+1 - On Acquia Cloud we've skipped 5.4 completely and currently run on PHP 5.5.23

Also, default PHP on latest Ubuntu-based distros is currently 5.5.12.

I think this isn't a debate any more. 5.4 is end of life in September.

If we move to PHP 5.5, I should note that the last time the Symfony folks were talking about this, they were looking at PHP 5.5.9 as the minimum for Symfony 3.0. Symfony 3.0 PHP 5.5.9 requirement

Centos/RHEL remains on 5.4.x by default (and RedHat provides security support to its own included packages).

Llater versions should also be available via software collections.

From a performance POV, according to @rasmus benchmarks, only PHP 7 will really make a difference: http://lerdorf.com/d8.html#/drupalbench (and D8 is 10x faster than with beta 4: http://lerdorf.com/d8.html#/drupalbench_old)

The 10x faster was page caching on by default.

#33 - Sure, but http://lerdorf.com/d8.html#/drupalbench shows 1378 req/sec on PHP 5.5 VS 2580 req/sec on PHP 7 which is still what we could/should aim for. Page caching on by default is what made the benchmarks fly from http://lerdorf.com/d8.html#/drupalbench_old to http://lerdorf.com/d8.html#/drupalbench

I'd like to advocate for a minimum version requirement of PHP 5.5 for stability reasons.

Running Drupal 8 (beta 7) in a RHEL production environment causes consistent segfaults in certain stacks. The stack we're running was using PHP FPM 5.4.16 with Nginx 1.4.4 and Memcached 1.4.4. We're also running Zend Opcache.

While debugging issues with node edit forms using memcache (we tried both memcache and memcached libraries), the node edit pages would consistently segfault and return a 503. We had success switching from ASCII to binary mode with memcache, but that introduced other issues.

We had fairly consistent segfaults in syslog, despite the fact that most pages returned 200 responses and looked OK. This was tracked down to Zend opcache garbage collection. We briefly considered disabling Zend Opcache (for debugging purposes only, since running without opcache isn't an option), but testing was nearly impossible after that. After the page was rendered and sent as the HTTP response, FPM would segfault quietly. The segfaults didn't cause visible issues unless actively tail'ing logs. That happened even under very light load (like during initial load testing).

We switched to PHP 5.5.6, and there hasn't been a single segfault since.

@tobby and regarding #35, there has been a number of mentions of a bug in APCu. There are more but the only issue I can find at the moment is https://www.drupal.org/node/2488730#comment-9922612 .

(Edited to remove incorrect information)

Clarification: APCu does not ship with PHP 5.5.

APC (without the u) is both an opcode cache, and a key value store for php 5.4.* and below.
For php 5.5.* and above, php ships with zends opcode cache, so the APC developers pulled out the opcode cache and re-released the key-value store as APCu.

You will not have any segfaults in APCu if you are using memcache or memcached.

We need a re-check on these for mid-2015.

I don't think it's necessary to recheck this. It's a waste of effort. PHP 5.4 ceases to exist in less than 4 months.

Edit: Unless it's done to check for moving to PHP 5.6, after all PHP 5.5 will be EOL next summer :D

No seriously, can we conclude this now? I don't see any objections against it except that it is not the default version in CentOS and Redhat, but a newer version can be installed on those platforms. I am running PHP 5.5 on CentOS servers myself without any problems.

Shall we start working on a patch? We need to decide on the minimum PHP 5.5 point release. At a minimum we need to update the version checks in install.php and bootstrap.inc.

Is the test infrastructure ready for 5.5?

+1

EDIT: but perhaps we should figure out which version of PHP 5.5 needs to be the minimum?

#41 Not sure, but that doesn't block us from starting a patch already.

Another data point: https://twitter.com/mtdowling/status/603415290802614272

The new PSR-7-using version of Guzzle requires PHP 5.5, so if we want to upgrade to Guzzle 6 we have to upgrade to PHP 5.5. (Guzzle originally bumped their requirements to 5.4 because we had done so, so they took that as a promising sign it was safe to do. Turnabout is fair play. :-) )

I am +1 on bumping to 5.5 myself at this point. Otherwise we're likely to release within a month of when 5.4 is officially euthanized.

This might help us decide on a minor version: List of PHP security vulnerabilities.

At first glance nothing extremely serious seems to have affected PHP 5.5 so far. There have been many security fixes, but none that have a severe impact and are also easy to exploit.

The testing infrastructure is on PHP 5.4, so HEAD will be broken with a 5.5 requirement unless either the existing test bots get a PHP upgrade, or d.o moves to the new testbot. That makes this blocked on that.

Looks like Guzzle 5 will only have support for about a year: https://twitter.com/mtdowling/status/603603747856621568

However we could also add a PHP 5.5 requirement to all modules that use guzzle (aggregator, update, testing - any more?) - except that doesn't solve the test infra issue.

I don't think it's necessary to recheck this. It's a waste of effort. PHP 5.4 ceases to exist in less than 4 months.

Unfortunately, PHP's EOL announcements are often naïve at best, and completely out of touch with reality at worst.

Case in point: http://w3techs.com/technologies/details/pl-php/5/all shows 9.2% usage of PHP 5.5. 5.4 at 30.1%. 5.3 at 41.6%.

By requiring PHP 5.4, Drupal 8 already gives a certain finger to 41.6% of PHP's install base. There were technical reasons for this, so that's fair enough. But what tangible benefits do we gain by reducing that by a further 30%?

As far as Guzzle goes, I agree with catch. Any module that requires it can add a PHP 5.5 requirement to their info file, without requiring us to increase the minimum PHP version for D8 as a whole.

webchick: To be equally fair, there's quite a bit of chicken-and-egg involved in that question. And also a question about which servers are going to be running Drupal, and which are a forgotten PHPBB installation from 2010. :-)

I don't think it's chicken/egg, really. Just look at the data. PHP 5.3 was EOLed in August of last year. And despite having almost a year of zippo security updates, and every major distro listed in the issue summary shipping with 5.4+ by default, PHP 5.3 still represents 41.6% of PHP 5 installs. (Granted, PHPBB installs from 2010 is some portion of that, but almost half of all PHP 5 installs? Doubtful.)

So what possible reason do we have to believe that suddenly hosts are going to see the light and respect PHP 5.4's EOL announcement and thus upgrade to 5.5 in a timely manner, if they didn't for 5.3?

Btw, I do want to point out that I'm not necessarily opposed to doing this. I'm just opposed to doing this without sufficiently justifying the tangible benefits we get for deeply cutting into Drupal 8's potential usage base.

Going back through the comments, it seems like the tangible benefits are:

1. Since PHP 5.4 is likely to be EOLed by the time Drupal 8 ships (or soon thereafter), so by forcing this requirement on our users, we would be preventing them from using unsupported PHP versions and possibly getting their servers compromised via a PHP security hole.

   However, that's quite overstepping our role as a "mere" PHP application (it's the host's job to keep the host safe, not ours). This "nannying" role is also not one we've ever traditionally taken on. Drupal 6 shipped with support for PHP 4 until six years past PHP 4's EOL. And while D7 did take a much more activist role in PHP's adoption via the GoPHP5 movement (which was both very awesome and very necessary), we nevertheless only required 5.2 (and still do, 4+ years later), which was EOLed literally the day after D7 shipped.

2. PHP 5.5 provides new language features such as "try-catch-finally" and being able to use expressions inside of empty(). However, contrib modules that want to use those constructs can just make their particular modules dependent on PHP 5.5. Drupal 8 core does not need to impose this restriction itself, esp. for nice-to-have syntactic sugar that most users will care absolutely nothing about.
3. Symfony 3+ requires PHP 5.5. However, we already know that 8.0.0 will not ship with Symfony 3, and that we can increase Drupal's PHP requirements at any point after release. So that too seems not an argument for doing this now, versus waiting until PHP 5.5 has some halfway decent marketshare.
4. Guzzle 6 requires PHP 5.5. We could either stick with Guzzle 5 for the first year and move to Guzzle 6 in 8.2.0, and/or we could add PHP 5.5 requirement in the modules' .info files that make use of Guzzle.
5. We could use PHP 5.5's password hashing over our own custom implementation #1845004: Replace custom password hashing library with PHP password_hash(). However, that feels like a nice to have. It's also possible we could do this in a minor release, after 8.0.0 and once PHP 5.5 has some halfway decent marketshare.
6. PHP 5.5 ships with an opcode cache by default. Now this one is interesting, if there are some benchmarks that demonstrate it having a significant performance improvement over PHP 5.4+APC. However, #34 seems to imply that any performance difference is negligible (though PHP 7 is a different story).
7. Someone had segfault errors that stopped when they upgraded to PHP 5.5 (this needs much more digging into to figure out root cause, also we'd also need some evidence that a large portion of users will hit this problem, worthy of off-setting the adoption hit).

So based on that list, I'm not seeing a "silver bullet" here which says we should obviously require PHP 5.5. Open to critique on that thinking, however.

TL;DR: Supporting 5.4 as a minimum in D8 would be keeping in step with what we've always done, which is make our minimum requirements strike the right balance between widest install base possible while giving us the techincal capabilities we need. And, as dropping PHP 4 support in D6 has proven, we're not locked into whatever we make the minimum requirement in 8.0.0 forever. When a compelling reason comes up to force the use of PHP 5.5 (such as Symfony 2.7 EOL which necessitates a move to Symfony 3), and/or when PHP 5.5 usage becomes far more commonplace, we can adjust the minimum requirements then. Modules that want to stay on the bleeding edge can simply require PHP 5.5 in their .info.yml files, just as they can now.

@webchick, that data is a bit misleading. Since it is counting website installations it is backwards looking. With an average lifetime of 5 years for small business sites these numbers are skewed by millions of Wordpress installations that are running on old servers.

We are not the only major framework that has had this discussion. PHP 5.5 will also be required by Zend Framework 3 (source) and Symfony 3 (source). Both are scheduled for release later this year.

Guzzle 6 requires PHP 5.5. We could either stick with Guzzle 5 for the first year and move to Guzzle 6 in 8.2.0, and/or we could add PHP 5.5 requirement in the modules' .info files that make use of Guzzle.

Symfony 3+ requires PHP 5.5. However, we already know that 8.0.0 will not ship with Symfony 3, and that we can increase Drupal's PHP requirements at any point after release. So that too seems not an argument for doing this now, versus waiting until PHP 5.5 has some halfway decent marketshare.

Things are not as simple as you think, as both Guzzle 3 and Symfony 3 are coming with API changess, so especially in the case of Guzzle we better update it rather earlier than later.

Guzzle 6 requires PHP 5.5. We could either stick with Guzzle 5 for the first year and move to Guzzle 6 in 8.2.0, and/or we could add PHP 5.5 requirement in the modules' .info files that make use of Guzzle.

I don't think we can upgrade from Guzzle 5 to 6 in a minor release without breaking our backwards compatibility policy, unless we find a way to mark an entire external library as @internal. We can do this for Symfony 2.8 -> 3.0 (if everything goes OK) because that is only going to be dropping assorted backwards compatibility layers as opposed to changing non-deprecated APIs. There's the option of breaking the backwards compatibility policy in 'exceptional' circumstances - but we should only use that option for things we couldn't anticipate, which since we're discussing this now isn't the case.

That leaves .info.yml - but note we'd have to do that for update module - which means no module update notifications or usage stats for people running 5.4. Also system module currently uses Guzzle in system_retrieve_file() (which is then used by locale module for downloading translations and update module again). However I think we could probably drop system_retrieve_file() before release candidate and have those two places use Guzzle directly so the dependency is explicit. That leaves whether allowing people to run Drupal 8 on PHP 5.4 without update module is better than not allowing them to run it at all.

Of the three options, the PHP 5.5 requirement seems the least disruptive both before and after release - unless you're on a PHP 5.4 host of course. My main concern with PHP 5.5 isn't that lots of hosts aren't on it (Drupal 8 usage will probably really get going around the point we drop 5.4 support anyway), but how well Drupal 6 and 7 run on it - since being able to run all three versions on the same server helps people trying to upgrade or with a few sites across the different versions on the same host.

I was in favour of keeping 5.4 support if it wasn't going to be a burden, I couldn't see any of the 5.5 features that were really worth making it the minimum requirement. However, keeping up with the other libraries is much more compelling, I guess that is something we have to get used to with so much of core depending on external libraries

Upgrading to Guzzle 6 might be something we want to consider since that is now PSR-7 compliant?

catch: Good point on Drupal 6/7. I know there are people running Drupal 7 on 5.5 successfully, so that doesn't seem to be that problematic. (The last significant upgrade bug was 5.4's pickier bug reporting; 5.5 and 5.6 are reportedly very smooth upgrades.) Drupal 6, though, is an open question. Without a test suite is there a way for us to get a good sense of that? Or rather, what would you consider an acceptable level of confidence that D6 will run on 5.5? (Which, D8 questions aside, is something we ought to be doing anyway as long as it's a supported release.)

Without a test suite is there a way for us to get a good sense of that? Or rather, what would you consider an acceptable level of confidence that D6 will run on 5.5?

I don't think there is a way apart from large 6.x sites successfully running on 5.5 and reporting that back anecdotally, which I personally haven't heard about.

AFAIK, DrupalCI will have support for testing in all PHP environments, so we should know then, and this issue is blocked on DrupalCI deployment regardless.

@webchick I don't think 6.x has enough of a test suite to report useful failures though. That'll definitely be true for 7.x though.

Yeah, that's true. D6 is a lot more swiss cheese. There are a couple of hundred tests though that would at least act as a smokescreen.

Responding to a few points, I'll try and update the issue summary later today:

that data is a bit misleading. Since it is counting website installations it is backwards looking. With an average lifetime of 5 years for small business sites these numbers are skewed by millions of Wordpress installations that are running on old servers.

Well, I would say that "backwards looking" is by design. Drupal 8 will receive better adoption if people can run it on the host they already have, versus also factoring a host migration at the same time as incorporating a new platform.

We are not the only major framework that has had this discussion. PHP 5.5 will also be required by Zend Framework 3 (source) and Symfony 3 (source). Both are scheduled for release later this year.

This is certainly another point in favour of the change. But we must remember that Drupal's target audience is vastly different from Symfony, ZF, or Guzzle. Those products are aimed squarely at developers who most likely run their own puppetized docker wakka wakka VMs, versus Drupal's audience of predominantly non-technical site builders are victim to whatever version of PHP is provided to them by their web hosts.

I don't have strong feelings about this atm and I actually use php 5.4 in production.

That said, my local D6(pressflow) development is done on PHP 5.6.9-1+deb.sury.org~vivid+2 and have never noticed any problems other then having to turn down deprecation warnings. Also quite a bit of contrib turned on.

SELECT COUNT(*) FROM system WHERE filename like 'sites/%/modules/contrib/%' AND status = 1;
+----------+
| COUNT(*) |
+----------+
|      165 |
+----------+

While updating the issue summary (which is going to take awhile) I noticed something interesting.

Symfony 2.7 will be supported until May 2019 (most likely about halfway through D8’s release cycle). The first LTS version of Symfony 3 is not until 3.3, which will be released May 2017, supported until May 2021 (hopefully at the end of D8’s release cycle, or very nearly so). Every prior version of Symfony 3 ends its support before 2.7 does, so switching to 3.x before then would represent a step backwards in terms of longevity of support for our users. :\

Ok, did my best with the issue summary update. Tried to keep the tone neutral, but may have failed in places.

Note that this issue is technically postponed on #1867192: Testbots need to run on 5.4, 5.5, 5.6 and 7, but leaving it active so as not to be perceived as shutting down discussion.

I also am leaving the "needs issue summary update" tag, because I did not update the survey of various hosts/distros/etc. since I think requiring PHP 5.5 is a bad idea. :) So someone else who thinks it's a good idea can do all of that work.

And after doing all of that, really the only compelling reason left for me to upgrade to PHP 5.5 is that Guzzle 6 requires it. And for that, I'd rather handle this with a diplomatic request to the maintainer to reduce the minimum requirement. He's been very easy to work with in the past, and might oblige, just as the PHPUnit maintainer did.

Bah. :) Almost didn't fail at HTML. ;)

Upstream Guzzle request filed here: https://github.com/guzzle/guzzle/issues/1092

Thanks for the great issue summary update!

Updating the issue summary with numbers from https://wordpress.org/about/stats/ which are also pretty depressing (albeit "downmarket" from Drupal 8).

5.5: 8.7%,
5.4: 39.3%
5.3: 34.9%,
5.2: 14.8%.

Yes, you read that right. The version of PHP that received zero security updates starting the day after Drupal 7 came out (6 Jan 2011) has more usage atm than PHP 5.5. :'(

Just one more issue summary update for the link to the Guzzle upstream issue and now I'm officially done touching this issue for at least the next few hours. ;) Sorry for all the noise.

Before I check out, when folks are updating the hosts/distros/tools tables, maybe also include the date in the bullet point of when it was last checked? Unfortunately, Drupal node revisions lack a "blame" option. :)

I've been researching the hosts that were marked with "needs update" and it's very promising. All of the ones I checked have now support for PHP 5.5 except one (Bluehost) but this seems to be a "lowest of the low" 4$/month host.

Most have an option to upgrade the PHP version in an existing hosting packages to a higher version through a web UI. The ones that are focused on VPS / dedicated server hosting don't, but if you are using a VPS you should have enough sysadmin chops to take care of this yourself anyway.

So it looks like even if your old site is still running on PHP 5.3 then chances are that you are just a phone call or button click away from being able to run PHP 5.5.

I don't think there is a way apart from large 6.x sites successfully running on 5.5 and reporting that back anecdotally, which I personally haven't heard about.

When I was writing a large part of the D6-D8 migrations I had a D6 instance running on 5.5/5.6 for months. There were deprecated warning errors in key places like manage fields and I had to make some changes to mbstring.* settings because _unicode_check() was failing but other than that, functionally everything seemed to work.

Updated distribution list regarding CentOS, particularly regarding IUS and the fact that I know people are still building CentOS 6 servers b/c of some of the changes that happened in CentOS 7.

Warnings notwithstanding, we are running a couple D6 sites on 5.5 without issue.

Funny story! My web host apparently today updated the server hosting my Drupal 6 blog (insert comment about the cobbler's kids here) to PHP 5.6.6 without telling me. Someone on Twitter informed me there were errors showing on the site. Specifically, a bunch of "strict warning: Non-static method should not be called statically" errors from Views. I updated to the latest versions of core, Views 2 (remember that thing?), and a few other modules and the errors disappeared. No other issues to report so far. Just another datapoint, albeit not a particularly complex site.

So far the anecdotes for Drupal 6 on 5.5+ seem favorable...

Responding to comments on the Drupal and PHP versions, I have a Drupal 7 site run on PHP 5.6 and I don't see any issues. It is a fairly heavy site with moderate traffic (around 2M page views per month) and it is working fine and fast. I keep an eye on the error log too and I don't notice any PHP related notices or warnings.

(Clarifying that we are talking about the end of security fix support for the D8 LTS with Symfony 3.3's lifetime, because seeing "D8 release cycle" and "2021" in the same sentence was like that thing where Darth Vader strangles you at a distance. Carry on.)

(Fixing list markup.)

Adding some comments after seeing a request from @Crell on Twitter.

In January this year we completed the upgrade of one of our largest client sites, running a mixture of Drupal 6 (Pressflow) and 7 sites, to PHP 5.5. The project had originally started as an "upgrade to PHP 5.4" project, but various factors meant that by the time we'd done the work to upgrade to 5.4, the extra effort to get to 5.5 was minimal. The sites had large numbers of contrib modules (easily over 150 across them all), and custom modules.

A few thoughts from that experience:

• A majority of Drupal 6 sites will likely be running on PHP 5.2 or 5.3. The effort of going 5.2 -> 5.3, and 5.3 -> 5.4, was significantly higher than going from 5.4 to 5.5 (from a Drupal compatibility perspective. Once on 5.4, moving to 5.5 has miminal backward-incompatible changes
• We're running PHP 5.5 on Redhat & CentOS using the Webtatic repos (https://webtatic.com/packages/php55/) so although the default version on Redhat/CentOS is lower, it's reasonably straightforward to do the upgrade of the packages - if you've got access to your host to do so.
• Core was relatively painless through the upgrade, the bigger challenge was in contrib - particularly Views as Crell has mentioned, Panels, CCK, Services, and a few others - a lot of patches are out there in the contrib issue queues waiting to be committed so I'd think we'd need a community push on getting these issues committed if we wanted to increase minimum versions across the board
• Custom code compatibility will also be a factor - probably the most common change we had to make was due to the removal of call-time pass by reference in 5.4 (http://php.net/manual/en/migration54.incompatible.php), I don't know what our position was on this when we remove PHP 4 support?
• It's worth considering the impact of opcache being part of PHP 5.5, and APC largely deprecated (except for APCu). We did see performance benefits compared to PHP54+APC but probably not significant enough to make it a key point in this discussion - it may make things easier for some users to get the performance benefits of an opcache though, as previously APC may not have been installed on some shared hosting setups. It also simplifies our advice/requirements for D8 as my understanding is we're now saying an opcache is pretty much essential to get a reasonable performance in D8 and we won't need to detail both options if we go to 5.5.

I guess the key would be, if we're going to require 5.4 for Drupal 8 anyway, and therefore expect Drupal 6 to run alongside Drupal 8 on a PHP 5.4 stack, we've already done the big leap around compatibility concerns - going further to 5.5 isn't likely to cause problems compared to 5.4.

Personally, I'd really like to see Drupal leading the way in promoting keeping up to date, across all Drupal versions, with the latest possible security and performance fixes - even ignoring some of the benefits of new features. If big projects like Drupal keep driving forward then hosts will be encouraged to keep up or lose out to those who will.

Side note - there are enough people who are keeping up with PHP versions that there are a good number of tags for issues which resolve PHP 5.4 and 5.5 issues in core and contrb, a selection at https://www.drupal.org/project/issues/search?projects=&project_issue_fol...

The first LTS version of Symfony 3 is not until 3.3, which will be released May 2017. Every prior version of Symfony 3 ends its support before 2.7 does, so switching to 3.x before then would represent a step backwards in terms of longevity of support for our users. :\

The first Symfony 3-compatible release will be 2.8 - see http://symfony.com/blog/transition-from-symfony-2-7-to-3-0-symfony-2-8-o...

This will be released in November 2015 and will also be an LTS. So it should be possible to upgrade to 2.8, stop relying on APIs deprecated in 2.8, then smoothly upgrade smoothly to 3.x from there. It will also be supported six months past 2.7.

2.8 will include deprecations compared to 2.7, so I think to be able to ever get onto the 3.x branch, we need to say that 8.x will be up to date with 2.8-3.0 and that module developers must not rely on code deprecated in 2.8. Seems better to go from to 2.8 either before release, or at least with lots of loud documentation between 8.0.0 and 8.1.0 (if 8.0.0 comes out before November).

Also I don't think we necessarily have to stay on Symfony LTS releases. We'll be doing our own releases every six months, so can potentially keep in step with each minor Symfony release. We're bound to continue finding and fixing upstream bugs and performance issues. Some of those might get backported to the LTS, but anything that doesn't we're then stuck waiting for up to three years instead of six months. At minimum we should be prepared to do that if we need to.

However the very last Drupal 8 LTS release will need to be on a Symfony LTS - so either 3.3 or 3.7 (although 3.7 doesn't come out until 2019 so very likely we'll need to stop at 3.3 and not go any further, unless an extra LTS pops up from Symfony before we're done).

http://php.net/manual/en/migration55.incompatible.php tl;dr: 5.5 doesn't break Drupal code unless you do something truly weird (function names with nonASCII characters because that surely won't break anything). This is not the case with 5.4.

To summarize #83 (awesome comment, thanks!) — #85:

From a D6-to-D8 POV, D8 requiring PHP 5.5 is practically speaking equivalent with D8 requiring PHP 5.4 — it's equivalently problematic.

That is right, strategies I have seen people applying for getting services up to date for Drupal 6 sites is to jump directly to PHP 5.6, as the update path from 5.4 to 5.5 or 5.6 is nearly trivial.
The problems I saw are mostly related to strict errors in various contrib modules, but I hope we can solve them over them ...

I think we can keep on 5.4 for now - generators are nice syntax, but Iterators provide the same - just with more boiler plate.

The PHP hash function is cool, but not a necessary thing as its very much not in the critical path - performance wise.

As D8 will be PHP 5.4, 5.5, 5.6 and 7 compatible, I don't see what we get from requiring 5.5 - except loosing market share on hosting.

Yes we will raise the bar at one point in a major version, but that gives people ample time to prepare after 5.4 EOL - the upgrade also will be smooth.

As we support all versions officially, this really is not a problem like with Drupal 7 or Drupal 6.

Fun-Fact: PHP 5.4 code is pretty much 5.3 compatible except for traits and [] syntax.

I have written a proof-of-concept PHP-Preprocessor that converts 5.4 code back to 5.3 code (yes, some clients still on 5.3 with LTS support) by parsing the PHP tokens, inlining traits (unless something uses the trait and overrides it in the same class, that is simple) and changing syntax back from [] to array() ... It pretty much worked as a PoC ...

Let's not forget that OpCache is part of 5.5, which means D8 should then have more predictable performance characteristics across hosts.

Not the most important thing, but helpful to keep in mind.

Fabianx: Igor beat you to it: https://igor.io/2013/07/26/evolving-syntax.html :-)

But yes, as others have noted 5.4's hard-retirement of call-time-pass-by-reference (which has been deprecated in the language since 4.2 or so) and "array in string context" becoming a visible error were the last significant breaks. 5.4->5.5->5.6 have been very smooth transitions. Glancing through the list of issues that tsphethean, nearly all of them seem to be 5.4 related, not 5.5 or 5.6. (There's only 2 exceptions that I spotted just from scanning the issue titles, and both are related to preg_replace with the /e modifier, which is deprecated and has a known alternative.)

#90 Thanks, that is awesome. So we can require PHP 5.3 then again with a compilation step in Core !111!!11 :-p (just kidding).

I have a list of patches I use to keep the PHP notices at bay: http://drupal.stackexchange.com/questions/154957/running-drupal-6-with-p...

We are using php 5.4 for D6 in production but I don't see a reason why we couldn't go to 5.6

5.6 is blocked on #2332295: Unicode requirements check not working with PHP 5.6 . Now THAT would rock my socks because http://php.net/manual/en/functions.arguments.php#functions.variable-arg-...

I would even argue (except I am not arguing anything any more so I am just gently raising the idea) going PHP 5.5 doesn't seem a big enough win to bother but PHP 5.6 is.

Which PHP 5.6 improvements make it worthwhile in your mind?

I sometimes get the feeling, in reading these discussions, that we focus too much on a static view of the world. For example, we look at what level of PHP 5.5.x support there is today at various webhosts and distributions. While that is an interesting piece of information, I believe it is not a basis for making the decision as to which level of PHP should be the minimum level for Drupal 8.

We know that requiring PHP 5.5.x would provide, at the minimum, the following benefits for Drupal 8:

1. Opcache - some performance benefits, and simplifying the advice/requirements for D8 (won't need to detail both options, APC and opcache).
2. New language features, including try-catch-finally, and being able to use expressions indside of empty(). We also get generators, function array dereferencing, ::class constant.
3. It will be supported for a materially longer time than PHP 5.4.x. In fact, if we stick with PHP 5.4.x, it is likely that D8 will release with a completely unsupported (and therefore insecure) version of PHP.
4. A new password_hash() function we could use to replace our custom phpass fork. This means less custom work for D8 developers.

Together, these are a good reasons to upgrade D8 to PHP 5.5.x. If we are planning to do it soon anyway after the release of D8.0.0, it makes a lot more sense to do it now so that developers can take advantage of these items today.

The question as to which distributions/webhosts support PHP 5.5.x today is not dispositive of the issue. The real question is what is the _trend_, and when do we think D8.0.0 stable is likely to be released.

Looking at where webhosts and distributions were a year ago, and where they are today, it is clear that the trend is strongly in favor of supporting PHP 5.5.x (if not PHP 5.6.x). According to the review as to support as of today, the majority of distributions and webhosts now support 5.5.x. This is a significant change from one to two years ago. Given that PHP 5.4.x will be EOL and completely unsupported this September, this trend can only continue.

Given that D8.0.0 stable is unlikely to be released in the next month or two, I would argue that by the time D8.0.0 stable is released, the vast majority of webhosts and distributions will either be supporting 5.5.x or be close to it. Further, it is not as if that when D8.0.0 stable is released, there is going to be a massive deployment of it. That is just the start of many people starting to play with it to determine when they will upgrade to it. It will be several months after that before there will be a significant number of live websites built with D8.

Drupal is not Wordpress. It is a higher performing, more robust, enterprise-level CMS, and stating that it requires PHP 5.5.x (and not an unsupported version, and therefore potentially insecure version, of PHP, i.e., 5.4.x) is simply consistent with the Drupal approach that we are more robust, we are more secure, we are more resilient.

#96:

But the point is that Drupal 8.0.0 supports PHP 5.4, 5.5, 5.6 and 7 out of the box. (see the DrupalCI critical requirement to test all major supported versions)

It is just that we _also_ support PHP 5.4 for users that want that.

Minimum Requirement != Support

Right, please read the issue summary. It already covers the point that we have never historically based Drupal's minimum requirements on what version of PHP was supported, but rather what gave us the biggest marketshare for the best technical capabilities. At the moment, that's definitely PHP 5.4. If we want to deviate from that, we need to justify it sufficiently. New information for this that's not already covered in the issue summary would be welcome.

Regarding #96, item 4, the password hash function is back-ported so that is not a reason for upgrading PHP.

Re #95 I linked in #94: variadic functions and argument unpacking via ...

Also, __debugInfo would be immensely helpful with typed data based entities.

It already covers the point that we have never historically based Drupal's minimum requirements on what version of PHP was supported, but rather what gave us the biggest marketshare for the best technical capabilities. At the moment, that's definitely PHP 5.4.

This is an excellent summary of how we've done things in the past and why. I think it still holds ground even today.

If we want to up requirements to anything higher than PHP 5.4, we'll need compelling technical reasons, OR change our point of view on WHY we want to support particular versions. Maybe going for the biggest existing market share is no longer reasonable, but pushing new market share (and new technologies) is. Maybe our existing strategy still suffices. This sounds like the one fundamental question that needs to be answered.

Has the world changed? If so, should Drupal change with it?

> Has the world changed?

Yes: PHP has a more predictable release cycle with less disruptive changes. From 5.2 to 5.3, from 5.3 to 5.4 the breaking is numerous and quite severe. There was no release policy either. However, from 5.4 to 5.5 and to 5.6 there is little breaking. PHP 7 will rock the boat enough that many won't transfer for a long time. In other words: we required PHP 5.2 because that was the minimum sane version and dragged the world along but now the world has marched ahead and all we can do is catch up. http://php.net/supported-versions.php has this. I suspect somewhat that the security support of 5.6 might be extended a little. By the time we agree on requiring and committing the patch for 5.5 there won't be any more normal 5.5 releases, only security support remains. There is no real lifecycle improvement in 5.5 and there is little technical either. PHP 5.6 will be security supported well into the D8 lifecycle and there's nothing else we can do as requiring PHP 7 is sheer madness.

Technically I don't think we've ever considered "market share" so much as availability. By that I mean what distributions are supporting and what's available from hosts.

If I am reading our list correctly the the only 2 shared hosts in the list not supporting 5.5 are Bluehost and Site5. That's a pretty small list. Should someone just maybe reach out to them and see what their plans are? If they have plans for updating, and we're ok with pointing people at build servers like ICU the support questions is sort of answered.

• Site5: http://kb.site5.com/php/how-to-change-your-php-version/#comment-1643881
  "asap" but no timeline
• Bluehost: I reached out to bluehost's live chat. They referred me to a ticket system that requires a bluehost account which I don't have.

Yes the great majority of hosts already seems to support PHP 5.5. From the ones we checked over 80% support it already and this number will probably rise leading up to September.

The "market share" numbers are misleading, they report current installs. It's not because 39% of current websites run PHP 5.4 that this also means that 39% of hosts are not supporting PHP 5.5. In most cases they do.

#105: Put another way, we have conflicting data. The W3Techs stats say that PHP 5.5 is still a small minority of the market. But finding a host that doesn't offer 5.5 as an option, if not by default, is seemingly difficult (although not impossible). Those seem contradictory, and suggest there's some sampling bias or other confounding factor at play.

Possible theories:

* Those hosts have a TON of old sites they're not upgrading, but are putting new sites on 5.5.
* W3Techs is reporting mostly non-mass-hosting, ie, company servers they control (and therefore could upgrade if they wanted to).
* W3Techs is reporting servers, not sites (or sites, not servers), which is throwing off the data.
* There's a zillion hosts running only 5.3 that we're not finding in our manual checks. Ie, we're self-selecting for "responsible" hosts, so over-reporting them. (Whether that's good or not is debatable.)

Obviously I'm biased, so I would argue that "it's hard to find a non-5.5 host" carries more weight.

Lies, damned lies, and Internet statistics. :-)

I would also note that we were aggressive in dropping old browser versions for Drupal 8, even those that aren't dead yet today (IE 8), on the grounds that we'd rather get laughed at now for dropping IE 8 prematurely than laughed at in 5 years for still supporting IE 8. This strikes me as a similar situation. While we can raise the required version in a minor release, as we've said, there is a cost to waiting as catch noted in terms of bumpier upgrades later and blocking our use of Guzzle 6. (I'm having flashbacks to Drupal 6 and jQuery 1.0.4...)

I think this is ultimately a framework manager call these days? Or release manager? I'm not certain...

Another 5.5 dependency: #2497691-3: Include Symfony PSR-7 bridge library.

(That's essentially the reference implementation of PSR-7. I've pinged MWOP to see if that could be lowered if needed.)

I think the most likely reason is because the hosts themselves are not controlling the PHP versions but the clients do. Clients on shared hosting will often not be aware that they are running an outdated version of PHP and will not go into their CPanel / Webmin / DirectAdmin interface to update to a newer version. Or the clients might be aware but scared of breaking things, or have the "Don't fix what's not broken" mentality.

If I were running a shared host I would also leave this matter into the hands of the clients. On the one hand you avoid the massive amount of complaints and support requests that will follow any forceful update to a higher PHP version, and on the other hand it will absolve you of any liability in case the client gets hacked due to using an outdated version since you were responsibly making newer versions available through the control panel.

Indeed: shared hosting represents the bulk of sites, and those sites don't upgrade PHP versions (If it ain't broke, don't fix it). Which doesn't mean they can't start a new site on a newer version of PHP.

Of course, this will always be a "best effort guess", it's extremely difficult to get cold, hard, unbiased data on this.

PHPUnit 4.7 was released this week, and its announcement included some interesting news about future versions:

• PHPUnit 4.8 will be the last version in the 4.x range, will support PHP 5.3-5.6 but not PHP 7, and will receive bug fixes until August 7, 2016.
• PHPUnit 5.0 will support PHP 5.6 and PHP 7.

Reasons for requiring PHP 5.6 directly in Drupal 8.0.0:

• We shouldn't introduce requirements on newer PHP versions without bumping core's major version, meaning that if we release 8.0.0 requiring 5.4, we can never make Drupal 8 require a newer version of PHP.
• We need PHPUnit 5 to be sure we can test all of PHP 7's features in the future.
• There will be contributed modules that require PHP 7 after a while, just like many Drupal 7 modules require PHP versions newer than 5.2. This happens and it's fine. Drupal CI and proper Composer usage haven't been figured out yet, so we cannot depend on those to allow contributed modules to be tested using custom PHPUnit versions.

We shouldn't introduce requirements on newer PHP versions without bumping core's major version, meaning that if we release 8.0.0 requiring 5.4, we can never make Drupal 8 require a newer version of PHP.

This isn't the case at all, see #2301501: [policy, no patch] Explicitly decide and document that mininum requirements for major versions might get raised in minor versions.

We need PHPUnit 5 to be sure we can test all of PHP 7's features in the future.

I'm not clear whether "doesn't support PHP7" means it just won't run, or it won't have any explicit support. if it's the former that's a problem for multiple PHP version patch testing, and if it's a choice between PHP < 5.6 and PHP 7 then I'd choose the latter since we'll be doing that eventually. But that's not been obvious at all from #2454439: [META] Support PHP 7.

Xano: I don't see anything in the announcement that says it won't support PHP 7. Regarding 4.8, it says:

PHPUnit 4.8 is the current beta release series of PHPUnit. It will become stable on August 7, 2015 and will be last release series of PHPUnit to support PHP 5.3, PHP 5.4, and PHP 5.5.

It doesn't even mention PHP 5.6, but I'm certain it will be supported. I can't imagine Sebastian wouldn't support latest-stable if at all possible. It looks like he was only listing the legacy-versions that will be supported.

While I'd love to jump all the way to 5.6 I don't think that's practical yet. (If it becomes practical in a year or two, I'm on board.) For now I think bumping to 5.5 is as aggressive as we can get.

I reached out to GreenGeeks hosting service live chat. They now support PHP 5.6 (they are going to update their webpage).

OVH web hosting now supports PHP 5.6 (see Which version(s) of PHP are available?) and will discontinue support for PHP 5.3 in September of 2015 (see About PHP).

#104: I contacted https://www.drupal.org/u/jaredsmith the Director of Open Source Outreach at bluehost to get an idea of if / when bluehost will support PHP 5.5.

I am personally still for 5.4, but at the same time find it important that hosts are updated.

Bluehost has the upgrade to either PHP 5.5 or 5.6 on its roadmap, but I'm not yet able to share any information about when that might happen.

@jaredsmith: are you able to share any information on why you haven't done it yet? Are there BC breaks you encountered that are responsible for your caution?

Sacrificing adoption for security would be a large break what we’ve traditionally done, which is making our minimum requirements strike the right balance between widest install base possible while giving us the technical capabilities we need. Drupal 6 shipped with support for PHP 4 until six years past PHP 4's EOL. And while D7 did take a much more activist role in PHP's adoption via the GoPHP5 movement (which was both very awesome and very necessary), we nevertheless only required 5.2 (and still do, 4+ years later), which was EOLed literally the day after D7 shipped.

I agree that raising the requirement to PHP 5.5 solely due to 5.4 being EOL by the time 8.0 is released would be a change from our historical practice. But that's not what's being proposed here. This issue is about the question of whether a new major Drupal release should hold back its requirements to an already EOL PHP version when there are actual technical reasons (such as upgrading to Guzzle 6 or paving the way to a future upgrade to Symfony 3.x) to not do so.

I don't think our history gives us an unambiguous precedent to follow. Here's why:

• Drupal 4.5.0 and earlier never specified the minor PHP version requirement. They only listed "PHP 4" as the requirement.
• The first major Drupal release to clarify the minor PHP version requirement was Drupal 4.6.0 (note that Drupal was not using semver at that time, so each 4.x release was a major release) which required PHP 4.3. At the time of 4.6.0's release (2005-04-15), PHP 4.3 had already been EOL for 2 weeks (2005-03-31). Given that, one could ask: why didn't Drupal 4.6.0 require PHP 4.4? I wasn't involved with Drupal at that time, so I don't know all the reasons, but one obvious reason is that there were no new language features in PHP 4.4 that were important to Drupal, so no need to raise the requirement for no reason.
• Drupal kept PHP 4.3 as the requirement all the way up to and including the release of Drupal 6.0 on 2008-02-13, despite 4.3 being EOL for 3 years already by then. However, PHP 4.4 wasn't EOL until 2008-08-07, so this isn't about 6.0 sacrificing PHP 5 adoption to support an EOL PHP, since PHP 4 wasn't EOL yet. Like above, it's just an example of Drupal not raising its requirement to PHP 4.4, because there was no reason to.
• Drupal 7.0 was the first major Drupal release after PHP 4's EOL, and it took advantage of that with a jump to PHP 5. There was debate on whether to jump to 5.2 or 5.3. There were certainly a lot of compelling language features (e.g., namespaces) in 5.3, but we chose the conservative option of 5.2. But, 7.0 released before (even if only by one day) 5.2's EOL. This was definitely an interesting precedent of not dropping compatibility until after EOL and also not holding back Drupal's release as a way of cheating around that, but it is not a precedent for what to do when a major Drupal version is released after a PHP minor's EOL.

So, while I agree that shared hosting companies are slow to retire PHP versions that become EOL, and that therefore releasing 8.0 without PHP 5.4 compatibility mere days/weeks (or whatever it ends up being) after its EOL will require many site builders to choose a non-default option from their hosting configuration, I disagree about this being a radical break from historical precedent.

#119 is my argument for why requiring PHP 5.5 for Drupal 8.0 would not be a qualitative shift in how we treat our users. In my opinion, it would maintain the status quo of:

• Don't abandon PHP version compatibility prior to its EOL.
• Even after EOL, don't raise the requirement without sufficient benefit to justify it.

However, that alone doesn't answer whether raising to 5.5 satisfies that 2nd point. Here I'd like to argue for why it does.

First of all, per #84, I think that by 8.2, we'll need to raise to 5.5, in order to use Symfony 3.1. I do expect there to be features and fixes between 3.0 and 3.1 that we'll want to keep up with. So, for me, this issue is only a question of whether to raise to 5.5 for 8.0 or for 8.2.

Secondly, I'd like to assume that the vast majority of hosting companies will at least offer PHP 5.5 or later as an option by the time 5.4 is EOL. It seems crazy to me for a hosting company to offer PHP, but not give people the option to use a non-EOL version of it for building a new site. I'm sure such hosting companies will be out there, but I don't think we should cater to them.

With those two assumptions in mind, let's classify shared hosting customers as follows:

1. People who will wait until 8.2 or later to build new sites on 8.x. These people will be unaffected by what the requirement is for 8.0.
2. People who will be building new sites on 8.0 or 8.1, for whom PHP 5.3 or lower is the then current hosting plan's default. These people will need to select a non-default PHP version to build their 8.x site regardless of whether PHP 5.4 or PHP 5.5 is Drupal's requirement. In fact, better for them to select 5.5 or later now than make the mistake of selecting 5.4 and then later needing to change to 5.5.
3. People who will be building new sites on 8.0 or 8.1, for whom PHP 5.5 or higher is the then current hosting plan's default. These people will be unaffected by whether 5.4 or 5.5 is the requirement for 8.0.
4. People who will be building new sites on 8.0 or 8.1, for whom PHP 5.4 is the then current hosting plan default, and for whom the hosting company will not automatically update them to 5.5 or later by the time 8.2 is released. These people will need to select the non-default option at some point. In my opinion, them needing to make that selection at the time they're building their new site is less of a burden to them than needing to make it when they're updating their site from 8.1 to 8.2.
5. People who will be building new sites on 8.0 or 8.1, for whom PHP 5.4 is the then current hosting plan default, and for whom the hosting company will automatically update them to 5.5 or later by the time 8.2 is released. This is the only group of people who benefit from us delaying PHP 5.5's requirement until 8.2, since it means they at no time need to deal with configuring their hosting setup.

So we have 3 groups of people who will be mostly unaffected, group #4 who would benefit from us raising to PHP 5.5 for 8.0, and group #5 who would benefit from us delaying until 8.2. I have no idea how to forecast whether #4 or #5 will be the larger group, but if they're approximately equal, then I think catering to #4 is better than catering to #5, because people encountering problems when updating from 8.1 to 8.2 will be people left with potentially insecure sites once there are SA's released for 8.2.

This can only be a BDFL decision, so assigning to him. That in no way is intended to discourage additional comments here in the meantime. Please continue to comment if you have new information or analysis to share.

I should also mention for completeness, that @Dries, @catch, @alexpott, @xjm, and I will be meeting next Wednesday, and this is currently one of the agenda items for that call (not necessarily to make a final decision, just to discuss it). @webchick is on vacation, so probably won't be on it. So, I ran my thinking (#119, #120) by her before she left (orally, before I typed them out), and if I'm remembering her response correctly, it was basically this:

That a PHP version's EOL isn't what matters. That Drupal 7.0 released 1 day before PHP 5.2's EOL and Drupal 8.0 will release X days after PHP 5.4's EOL isn't the point. What matters more to her is PHP version adoption in the real world. In early 2011, PHP 5.3's share of websites was ~10%, and that was not high enough for us to justify making it a requirement for 7.0 despite all the good things it offered. It took 2 more years after that for 5.2 to fall below 50%. Now, PHP 5.5's share of websites is ~10%, so why should we take the opposite stance of what we did 4 years ago?

My response to that is similar to #105: that when it comes to building new websites, the PHP version on which old websites are deployed isn't that important, and that instead what's important is the availability of the version in question. And that the EOL date is (or at least should be) a good proxy for the date at which the next version is very widely available.

@effulgentsia
+1

that when it comes to building new websites, the PHP version on which old websites are deployed isn't that important, and that instead what's important is the availability of the version in question.

And based on our investigations, the vast majority of hosts are already offering PHP 5.5.x (and many already PHP 5.6), and the few that are not (bluehost, site5) have let us know that it is on their roadmap, just that they can't give us a specific date.

I've got to think as a business matter, if these hosts know that Drupal 8.0 will require PHP 5.5, it should provide them with the impetus to finally schedule it.

Has anyone verified whether or not cPanel and/or Plesk are the limiting factor with PHP 5.5 adoption at commodity hosting and not the hosts themselves? I think it is a safe assumption that site-builders will be using control panels. In the past, both have been finicky about the PHP version they would work with, but I haven't had a client with a control panel in a long time. A quick look at the docs for both didn't confirm either way.

Has anyone verified whether or not cPanel and/or Plesk are the limiting factor with PHP 5.5 adoption at commodity hosting and not the hosts themselves?

CPanel has added support for PHP 5.6 a few weeks ago (source). Plesk already added support for PHP 5.6 in October last year (source).

Thanks, effulgentsia!

For me, the only compelling argument for maintaining 5.4 compatibility is the W3Techs stats that list 5.5 at ~10% adoption. Really, that's the only point in 5.4's favor.

However, in response I would repeat my note in #106: Where are those hosts? Nearly every host we can find is offering 5.5 at this point, in some form. The current versions of every major distribution are on 5.5 if not 5.6. That, to me, really makes me question the W3Techs stats. (Side note: They're also the source of the "PHP is 80% of the web" stat we like to keep quoting, which actually makes me a bit concerned that number may not be reliable either, but that's another story.)

I know a lot of hosts held off on 5.4 due to well-documented stability issues with APC, which is one reason APC was abandoned in favor of opcache to be embedded into 5.5. At this point, any host that is finally upgrading from anything previous to 5.4 should be upgrading to 5.5 or 5.4; upgrading TO 5.4 at this point would make no sense at all for any server.

So are we really sure of that 10% number? The other evidence we have for PHP version usage doesn't back it up, and without that stat there is no other compelling reason to stick with 5.4.

@Crell, that statistic tracks the PHP version that is used on existing websites, which says absolutely nothing about the PHP versions that can be used for new websites. Yes obviously there will always be old servers online that are running older versions of PHP, but that's irrelevant to this discussion.

The question is whether people can host their new Drupal 8 sites on PHP 5.5 and the answer is a resounding yes. There was only one host that we researched that doesn't currently support PHP5.5, but one of their representatives has answered that they plan to add support in the future (ref comment #117).

So at the moment 100% of the hosts we researched already support PHP 5.5 or plan to add support.

Added control panels to IS.

Now, PHP 5.5's share of websites is ~10%, so why should we take the opposite stance of what we did 4 years ago?

I realise you are paraphrasing here but this is not an argument in any constructive sense. It presupposes that the discussion we had 4 years ago is still relevant today and that it was done completely and correctly. We should discuss this again because:
- our stance to 3rd party libraries has changed, and with those our stance towards versions and compatibility should be reconsidered (guzzle)
- the speed with which websites are hacked has increased so we should reevaluate staying up to date vs conservative maintenance (drupalgeddon)
- Our ideas of the developer community have changed pushing for adoption of more professional and more recent dev methods and concepts. This requires developers to have an up-to-date skill set. This is quite a paradigm shift which led more conservative developers to fork. We should strive to adopt a "recent" php version to match our new stance on dev skill. And require the same from web hosters / stack admins as we do from developers. (OOP, namespaces, backdrop, etc)
- Speed requirements have changed. Google now favours the quick over the slow. Any speed gains that come with adopting a more recent version of php should be considered.

So really, yes we must have this discussion again, however exhaustive.

Re #126 and querying the PHP 5.5 usage statistic

are we really sure of that 10% number?

I have been looking for more statistics on PHP adoption and have found the following:

1) http://blog.pascal-martin.fr/post/php-versions-stats-2014-10-en.html The method used to obtain this data appears to be the same as that used by W3techs. It shows PHP 5.5 usage at 5%. It is worth noting that this data is 7 months older than the W3Tech stats which explains the variation in usage numbers.

2) http://seld.be/notes/my-view-of-php-version-adoption This data is from November 2014 too but uses different methodology to get its data. This data is heavily biased towards developers but nicely shows how the adoption changes over the year. If a one line message was taken away from this data it would be something like 'people developing websites are mostly using PHP 5.5.9.'

And a little off-topics but:
As I was searching for data I came across http://blog.ircmaxell.com/2014/12/php-install-statistics.html Which I am sure many of you will have seen previously. The summary hits home the point well:

This means that over 78% of all PHP installs have at least one known security vulnerability. Pathetic.

Check your installed versions. Push for people to update. Don't accept "if it works, don't fix it."... You have the power to change this, so change it.

Security is everyone's problem. What matters is how you deal with it.

Via the second link in #130, I stumbled upon http://typo3.org/news/article/php-minimum-requirements-for-typo3-cms-7/ — Typo3 CMS version 7 (which is already released) already requires PHP 5.5.

There's one group that's not in effulgentsia's list which is probably the most likely to run into a PHP version requirement issue either with a new install or an upgrade. This is people working at large organisations like universities that provide limited web hosting to departments/individual staff members. I'm thinking of example.edu/~jsmith type sites, or just slightly more advanced than that.

Found a couple of examples of places that still have this kind of service available (or at least docs for it):

http://www.umich.edu/~umweb/how-to/homepage.html
http://its.virginia.edu/homedir/web/

I checked if virginia.edu provided MySQL databases (it does) since that'd be a pre-requisite to installing Drupal (or Wordpress) at all, and also found out they've deprecated their service: http://its.virginia.edu/websupport/

How widespread and whether people are setting up new sites on this kind of service (compared to say 10 years ago) I'm not sure. If they're used for new sites, then they'll eventually get updated to newer PHP versions (although potentially very eventually). If they're only legacy, then they'll probably stay on PHP 5.2/5.3/54 or whatever they were on when they got frozen in time.

One anonymous source mentioned on irc that they know of at least one university running a similar service that was on PHP 5.3 last year - we already don't support 5.3 so 5.4 or 5.5 won't make any difference to that particular example either way. But let's assume a decent number of those services are on PHP 5.4.

That brings me back to effulgentsia's 4th group of people:

4. People who will be building new sites on 8.0 or 8.1, for whom PHP 5.4 is the then current hosting plan default, and for whom the hosting company will not automatically update them to 5.5 or later by the time 8.2 is released. These people will need to select the non-default option at some point. In my opinion, them needing to make that selection at the time they're building their new site is less of a burden to them than needing to make it when they're updating their site from 8.1 to 8.2.

If you're on a host where there's no control panel or support ticket to upgrade, but you just get what you're given until they do a system-wide upgrade, then this changes to installing 8.0.0 on PHP 5.4, then being stuck on 8.1.x indefinitely without any security or bug fix support at all, until the university hosting upgrades, or until you set up a shared hosting account and migrate to it.

While installing the day 8.0.0 comes out means you get a year to plan for this (or the host to upgrade), by the time we get to 8.1.4 we'll be expecting people to do both a minor version and PHP version upgrade within a matter of weeks or days from the initial install. Not nice for them.

However, if we require 5.5 straight-off, then someone with only access to that kind of host might have to use Drupal 7, Backdrop, or Wordpress instead of 8.0.0. Or they might have to make a special request to their IT department to get access to a host with a newer PHP version, or they might end up setting their own shared hosting account to run the site off.

To me all of those are preferable to giving the illusion that Drupal 8 is going to be OK for them, then presenting them with a nasty surprise 12 months (or much less) after the install. This is a case where 'adoption/growth' in terms of raw numbers starts to look really unhealthy for actual people using our stuff.

So given that I'd suggest the following:

1. Require 5.5 now - since we know we'll require it in a year or so anyway.

2. Set a goal (but not strict rule) not to raise the minimum PHP version requirement more frequently than every 18 months - to give people using the mnimum required version plenty of time to get off it.

3. Whenever we know we'll be requiring a new PHP version in a subsequent release, add a hook_requirements() warning to the next minor/patch release informing sites running the soon-to-be-unsupported-version that they're running an obsolescent version and will need to upgrade their PHP install within X months. That leaves it less likely that people will try to update Drupal before PHP and end up with syntax errors or get stuck on a zombie version.

4. Following on from #3, consider preventing new installs on the obsolescent PHP version X months before the minor version that raises requirements is out, even though we'd only show the warning on existing installs - to avoid the nasty surprise factor.

2. Set a goal (but not strict rule) not to raise the minimum PHP version requirement more frequently than every 18 months

I understand the rationale for requiring 5.5 before vs. after 8.0.0, but what's the rationale for continuing to push PHP minimum version increases every 18 months?

That sentence doesn't read great, note the 'not'.

Set a goal (but not strict rule) not to raise the minimum PHP version requirement more frequently than every 18 months

However we need to leave it open that we might raise the requirement during the 8.x cycle if something comes up - hopefully that's less likely (and almost certainly less soon) if we require 5.5 but won't know until it comes up (or until the LTS is released and it hasn't).

PHP 5.6 is the final version in the 5.x line. Let's assume Drupal 8.3, 8.4, or 8.5 will be the 8.x LTS, so released 18-30 months after 8.0. And then supported for a long time. So I think prior to tagging the 8.x LTS, we should evaluate whether to raise PHP requirement to 5.6 in order to not do it during the LTS lifetime.

Missed the "not" in there, sorry. :D That makes sense, thanks.

I presume we're only considering feature releases of PHP, of which as Alex noted there is only one more in the 5.x line. Assuming we're not planning to bump Drupal 8 to PHP 7 at any point (although in a few years that may not be a safe assumption), that means we're only looking at 5.6. So given catch's 18 month guideline, the question sounds like whether we go 5.4 now and 5.6 in 18-24 months, or 5.5 now and 5.6 in 18-24 months. 5.5 is just about to go into security-only itself, and loses all support in mid 2016, just about 12 months from now, so 18-24 months after 8.0 5.6 will be the oldest supported PHP version available. cf, http://php.net/supported-versions.php

Whatever we do, #132.3 (add a hook_requirements warning for "the next version will have a higher version requirement, be ready") sounds like a great idea. +1

@catch's first point in #132 is an important one. In addition to universities, other large organizations like governments often are in this situation. Basically any place where the hosting "department" is separate from the people who are building/planning the Drupal website, and where the hosting department has to support much more than just Drupal. We often forget those types of organizations in these discussions. Would be great if there was a way to get more data about that.

Related to the above, I think the issue summary is misleading in the "Survey of major distros to see what PHP they support" section since it doesn't mention earlier LTS versions of all the distros. For example it mentions Debian Jessie (which has PHP 5.6) but not the previous version, Wheezy (which has PHP 5.4). Wheezy was released in May 2013 and will still be supported for a long time (the LTS support date doesn't even seem to be officially set yet, but the previous Debian release has a 5 year LTS lifetime so one could guess May 2018 for Wheezy). These older Linux distributions are important to consider since more conservative hosting environments will tend to stick with them, and not necessarily want to update the PHP package to something that isn't part of the distribution.

All that said:

1. Require 5.5 now - since we know we'll require it in a year or so anyway.

This seems like a pretty compelling argument if it's true. Dropping support for a PHP version that still has a large audience (as PHP 5.4 almost certainly will still have a year or so from now) in the middle of a stable Drupal release sounds like a bad idea.

- Our ideas of the developer community have changed pushing for adoption of more professional and more recent dev methods and concepts. This requires developers to have an up-to-date skill set. This is quite a paradigm shift which led more conservative developers to fork. We should strive to adopt a "recent" php version to match our new stance on dev skill. And require the same from web hosters / stack admins as we do from developers. (OOP, namespaces, backdrop, etc)
- Speed requirements have changed. Google now favours the quick over the slow. Any speed gains that come with adopting a more recent version of php should be considered.

I think you're misunderstanding the reasons people had for forking Drupal - and PHP 5.5 also doesn't really introduce any major new development concepts compared to PHP 5.4.

Definitely agree that the performance improvements in newer versions of PHP are important, but that just means we should update the recommended version of PHP to the newest version possible as soon as we're confident that Drupal runs well on it (this is true for Drupal 7 just as much as for Drupal 8). But I don't think it's really a good argument for increasing the minimum required version.

Note that we can't meet the requirement of being on the latest libraries when we launch and support 5.4. #2493911-11: Update guzzle, goutte and mink-goutte-driver to the latest release

The question is:

Do we _need_ to update the minimum requirements to PHP 5.5 or even 5.6 for Symfony 3.x or Twig .x or any other library we use and plan to upgrade during the minor releases.

If that is the case we either need to hold off on updating those and as we already decided on Symfony 3.0, we would need to require PHP 5.5 now or strongly communicate that you have 12 months to upgrade with a warning in hook_requirements().

Overall my stance on that is:

- For updating to major new versions of libraries (that require a higher PHP version), we should hold off and do it in our next major release instead.
- If a library requires a new PHP version for a minor version upgrade, that is a bug in itself and should not happen with semver.

Overall that would mean (for major, minor, patch):

- Major version upgrades of libraries => Major Core upgrade (e.g. x.0.0)
- Minor version upgrade of library => minor core upgrade (8.x.0)
- Patch version upgrade of library => patch core upgrade - if not otherwise disruptable (e.g. 8.0.x)

Overall we need to judge the disruptiveness of a library upgrade the same as a core upgrade.

=> PHP 5.5 now (or strong warning that its required in 12 months - like: You still have 6 months and 28 days to update to PHP 5.5)

There should be nothing to force us requiring PHP 5.6 in Drupal 8's lifetime as there surely are distributions providing LTS for PHP 5.5 by then.

PHP 5.6 or 7 would then be for Drupal 9.

That would be my ideal world scenario when all used libraries support LTS releases.

As someone that works for one of these large archaic organizations I relate to most of what catch wrote in #132, and weep. What is often overlooked is a lot of this is dictated by legacy applications. I rarely deal with departments that have a website on a web server, or group of Drupal sites. It is usually multiple different web applications on the same machine, or belonging to the same group, or belonging to different groups. We are often handcuffed by the inability, lack of resources, or client motivation, to upgrade something outside of Drupal. (Yes, I know of a server around here running PHP 4, because some people have really old custom apps written a very long time ago. "Ain't broke, don't fix it")

So if Department of Random Something only has one web server and are looking to build a new website, and Wordpress will work as-is and Drupal won't, guess what they will choose. That might not be a demographic anyone cares about, but it will happen a fair bit.

I'm not actually compelled to argue one way or the other, but one thing that does concern me is the thought of raising the minimum through D8s release. If a PHP upgrade is needed to get from 8.2 to 8.3 (for example,) that scares me. For all the reasons above, a lot of people will get stuck on 8.2, and worse, they likely didn't know that was the future in store for them. Most of Drupal's user base is not well informed or connected, as with any software user base. (Stop assuming all these websites are being run by Drupal developers.) They won't know about these requirement changes until they happen, and certainly aren't likely to plan ahead for them. So if there is a major vulnerability discovered, be prepared to deal with a lot of aggravated people, since "upgrade to a more recent version" is not a solution they've been able to implement yet.

I'd be inclined to think do it now or don't do it at all. At least I can plan to tell people "Drupal 8 requires 5.5." If I go around telling people Drupal 8 is awesome and you should be fine hosting it but then one year from now they get stuck in a requirements trap, that can come across as a giant kick in the teeth.

If we don't go PHP 5.5 now, that means we stay on Guzzle 5, and contrib (for example, commerce payment methods) writes Guzzle 5 compatible code.
Since we can't break contrib in 8.1, that means staying on Guzzle 5 for all future Drupal releases, even once we jump on PHP 5.5
That's very problematic.

@Fabianx

There should be nothing to force us requiring PHP 5.6 in Drupal 8's lifetime as there surely are distributions providing LTS for PHP 5.5 by then.

PHP 5.6 or 7 would then be for Drupal 9.

That would be my ideal world scenario when all used libraries support LTS releases.

So the only case would be if a library raises the requirement to 5.6 and 8.x is going to be supported longer than the LTS for that library (or non-LTS release if there is none). Which would be the case if Guzzle 7 comes out on a similar schedule to Guzzle 6 with no other changes in their support cycle.

In that case we have five options:

1. Don't upgrade - maintain our own fork to backport security fixes etc.
2. Try to upgrade but build our own adapters to maintain backwards compatibility with the old library - may or may not be possible.
3. Lobby the library authors to either lower the PHP requirement or maintain an LTS, may or may not work.
4. Consider changing our own LTS policy to support the last minor version on 5.5 longer (sounds horrible but a long time between now and then).
5. Make the next 8.x release the LTS and start Drupal 9 development so that the 8.x LTS finishes quicker. With the argument that major version library upgrades we can't follow are a compelling reason to open the 9.x branch.

We can't predict whether this will happen or not, but given we know it's already the case for Guzzle and that Symfony 3.0 is planning to do it with 5.5, that keeps pointing me to just requiring 5.5 now and hope this doesn't actually come up...

@davidhernandez

I'd be inclined to think do it now or don't do it at all. At least I can plan to tell people "Drupal 8 requires 5.5." If I go around telling people Drupal 8 is awesome and you should be fine hosting it but then one year from now they get stuck in a requirements trap, that can come across as a giant kick in the teeth.

Right I think everything we can do to avoid the 'giant kick in the teeth' is important, and to me personally I'd rather turn people away than invite them in then kick them in the teeth if that's the choice.

So if Department of Random Something only has one web server and are looking to build a new website, and Wordpress will work as-is and Drupal won't, guess what they will choose.

This is true, but they also have at least 2 years of Drupal 7 support remaining - and people will still be launching Drupal 7 sites for 6-12 months after 8.0.0 is released, if hopefully not starting many brand new projects on it. Also if those hosts are running PHP 5.3 currently, it's already too late for them.

I had a quick check to see if there's any movement on the Wordpress side to increase requirements, and it looks like not, but in case anyone was thinking of looking at that, the following were interesting:

http://coenjacobs.me/wordpress-plugins-require-php-5-4/
http://planetozh.com/blog/2014/01/why-wordpress-should-drop-php-5-2/
https://core.trac.wordpress.org/ticket/26909

Short version: they won't drop even PHP 5.2 support for as long as they can stick it out, but looks like at least some plugin authors were trying to up their own requirements to PHP 5.4 in January last year (and add a PHP version check plugin requirement to Wordpress core).

Thanks for all the discussion on this, and the amazing issue summary that came out of that. I've given this some thought and had a chance to discuss it with all my co-committers for Drupal 8. I believe we should go ahead and require PHP 5.5 before the Drupal 8.0.0 release.

Let's ensure to make a patch for that ...

Oh and that is super cool!!!! Thank you dries

Here is a patch. This is how I generated the changes:

hw@d8:/var/www/d8task/core-[git 8.0.x] $ composer require php:">=5.5.0"
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Writing lock file
Generating autoload files

Of course, the discussion now should be if PHP 5.5.0 is enough? The testbot may also have something to say.

Changes to INSTALL.txt are missing, and I guess there should be a requirements hook somewhere that enforces PHP 5.4 on installation? That should now be 5.5. See #2152073: Bump Drupal core's PHP requirement to 5.4.2 for an example what should be changed.

@klausi, good points. I have made the changes but since the testbots run PHP 5.4, I am thinking this patch will fail. I think there is already a blocker tag on the issue, or do we need to add another specific one?

Current recommended PHP 5.5 version is 5.5.26 - Should we aim for that?

@anavarre: I don't think that would work. We should see what LTS versions support and try to use that if we can justify it. For instance, there were a lot of releases in PHP 5.4 after 5.4.5 (many of them security updates), but we didn't move from 5.4.5.

Thanks, Dries :).

The failures are expected. It can't move ahead until the testbots use PHP 5.5. I am not sure how to proceed there.

@Fabianx, are you saying we need another issue for the patch? :)

I think we need a new, critical issue/patch to increase the requirement, and it will need to be postponed on PHP 5.5 test bots.

However we can probably work on the Guzzle 6 update in parallel, it just won't be committable until there's a green test run.

Created #2508231: Raise minimum required version of PHP to 5.5.9 and uploaded the same patch there. Setting this one back to Fixed.

Updated issue summary to reference Debian Wheezy, which has PHP 5.4 and will likely be supported until May 2018 (see comment #138). As mentioned in that comment it is likely the issue summary is incomplete for other Linux distros also.

#2524432: Suggest PHP 5.6 as the recommended version

Added the current LTS Opensuse distro to "Survey of major distros to see what PHP they support".

Please note that the current LTS distribution is 13.1. and official supported php update in OpenSuse 13.1 is PHP 5.4.20.
OpenSuse 13.1 will be supported by Evergreen-project till end of 2016 (https://de.wikipedia.org/wiki/OpenSUSE).

Thus the requirement of PHP 5.5 can reduce the distribution of Drupal 8 at least in German-speaking countries in this and next year.

@hermann77 The decision has been made #2508231: Raise minimum required version of PHP to 5.5.9.