Raise minimum required version of PHP to 5.5.9

@hussainweb
Is there a similar issue for the bots?

@dawehner that's #1867192: Testbots need to run on 5.4, 5.5, 5.6 and 7 and also #2467925: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1.

I've updated https://www.drupal.org/node/270/revisions/view/8393825/8579041

Otherwise marking this postponed. Patch looks good.

+++ b/core/composer.json
@@ -4,7 +4,7 @@
-    "php": ">=5.4.5",
+    "php": ">=5.5.0",

Symfony 3.0 requires 5.5.9, so I think that should be our minimum.

Symfony 3.0 requires 5.5.9

Is there a link to get the reasons behind?

https://github.com/symfony/symfony/commit/fddcb86c31a7bde7b70bad8c3e3d2c...

It's the version shipped with latest Ubuntu LTS and also the lowest 5.5 we can test on Travis

¯\_(ツ)_/¯

Sounds like a good reason :)

Sigh. I will pretend I am not the first to read "Survey of major distros to see what PHP they support" and the decision on which minor version to support was surely not based solely on what others do. Surely not, right?

This seems pretty clear cut to me. If Symfony 3.x requires PHP 5.5.9, we shouldn't set Drupal 8.0.0's requirement to less than that, since we know we'll want to update to Symfony 3.x at some point early in D8's lifetime. And if Ubuntu 14.04 LTS includes PHP 5.5.9, then we shouldn't set Drupal 8.0.0's requirement to more than that unless we have a compelling need to.

Sigh. I will pretend I am not the first to read "Survey of major distros to see what PHP they support" and the decision on which minor version to support was surely not based solely on what others do. Surely not, right?

Yeah I agree with @effulgentsia, we have a clear upper limit, but yeah I think I understand your point. You question why symfony went with the highest possible in that range,
even there might be not a pure PHP level reason to do so?

You misunderstand me. I have nothing against 5.5.9. What I have a lot against is this process: we have always been an absolute miser about raising versions for very good reasons. Instead of studying the shipped OS minors and/or hosting support we jumped to 5.5.9 because of what 3rd party software does. It's only by coincidence that we didn't jump over Ubuntu LTS for example. This is absolutely and horribly wrong. Further see my comments #2290261-49: Revert php_fileinfo requirement and #52.

Edit: there's a Hungarian saying when someone (typically kids) tries to defend their actions by saying "I did it because X did it too" and then the answer is "well, if X jumps into a well are you going to jump after him?"

I would guess this https://twitter.com/guilhermeblanco/status/532257853416173568 lead to 5.5.9 .

Edit: but say, Symfony decided their favorite bug was https://twitter.com/cakper/status/532527666692628481 this one. By the exact same logic you would've went over Ubuntu LTS without batting an eye!

I looked for why travisci starts at 5.5.9 and it's also Ubuntu LTS http://docs.travis-ci.com/user/languages/php/

As seen in the "Survey of major distros to see what PHP they support" section of that issue summary, the lowest PHP version among major distros is 5.5.9 so that's our target.

As I pointed out earlier in that issue (#2296557: [policy] Require PHP 5.5) the issue summary there is missing important information about a lot of the distros (seems to mostly be mentioning the most recent version of the distro only, not others which are currently supported) so I'm not sure we actually know that there aren't any major ones that have PHP < 5.5.9. (I updated it for Debian Wheezy now, which has PHP 5.4... but I guess here we'd be looking for something that's PHP 5.5 and < 5.5.9.)

but I guess here we'd be looking for something that's PHP 5.5 and < 5.5.9.

Yes I think this is the main question.

However looking at http://www.sasaprolic.com/2013/02/list-of-current-php-version-in-major.html from 2013, it looks like what happened is Ubuntu went to PHP 5.5 earlier than any other release, hence landing on PHP 5.5.9 (which is a relatively low version number), then all the other distros moved to 5.5 later so ended up starting with later version numbers.

Then from December 2014 we have http://blog.ircmaxell.com/2014/12/php-install-statistics.html which shows only Ubuntu Trusty and Ubuntu Utopic on 5.5, with Utopic having moved to 5.5.12.

Given that, it seems unlikely another distro moved to PHP 5.5 in between Trusty and Utopic but decided to use an earlier point release of 5.5.

Just installed Drupal 8 beta 12, and there didn't appear to be any checking for the PHP version number, so that my Status reports shows:

PHP (multiple statement disabling) 5.4.25 (more information)
PHP versions higher than 5.6.5 or 5.5.21 provide built-in SQL injection protection for mysql databases. It is recommended to update.

Shouldn't the check be before even the database configuration is made?

@iantresman Please read the issue again - this issue will raise the minimum PHP version from 5.4.5 to 5.5.9. It is currently postponed until we are able to run our automated tests on PHP 5.5 (the test servers currently run 5.3 only).

Your server meets the minimum requirements for Drupal 8 beta 12, but will not meet the minimum requirements for Drupal 8.0.0. The installer will refuse to run on older versions of PHP.

I also think it is no option to do such a change post release, but this change may dissallow a D6 to D8 upgrade as D6 cannot run on 5.5.9 as I know. At least D6 is currently not supported on 5.5. therefore a 5.4 version that fit for both D6 and D8 was chosen in near past...

D6 doesn't work on PHP 5.4 either, so this was discussed when the minimum version was bumped to 5.4. Because the upgrade now uses migrate, you don't need to be able to run Drupal 6 on the server doing the upgrade, you just need to be able to run the upgrade scripts, which will be written to support the necessary version of PHP.

Does migrate needs actual D6 code to run or does it only need to have the database access ?

Does migrate needs actual D6 code to run or does it only need to have the database access ?

Migrate is executed in the context of the destination site, and fetches the entries using direct DB queries, so it doesn't need D6 to run.

Oh right, sorry I misread what ianthomas_uk said.

Huh? I thought we support both on the same box, but OK. :-)

I'm running both D6 and D5 on php 5.4. D5 has an unofficial patch, but D6 runs without patches for sure.

That seems a non-issue then if that's the concern. I've run d6 in my 5.5 and 5.6 testing environment without significant problems(have to turn down the error level much like 5.4). https://www.drupal.org/node/2296557#comment-9969969

I hope I'm not out of line, but I think it would be appropriate to limit the discussion of "should" to the parent issue rather then drawing it out to a second issue. This issue is about implementing that decision.

This was discussed in some depth from #2296557-55: [policy] Require PHP 5.5 downwards on the parent issue. It's unlikely that D6 will run into problems with 5.5 that it didn't already with 5.4 - and there's still some time to submit patches to improve that if it does.

Note the issue on that topic for 5.4 was #2135203: Fix all known PHP 5.4 incompatibilities on D6 and D7 that are critical or would prevent a migration to D8 (and as pointed out there, it is important to be able to run Drupal 6 on the minimum PHP version for Drupal 8) - we could create the exact same issue for 5.5 if it's necessary, but sounds like it might not be necessary. Not many breaking changes between 5.4 and 5.5 supposedly, and looking at https://www.drupal.org/project/issues/search?projects=&project_issue_fol... I don't see much there that looks serious.

One week today active support will end for PHP 5.5 (http://php.net/supported-versions.php), therefore why would we plan to launch D8 with a PHP version which is not actively being supported. Yes, I understand it'd still get security fixes for another year, but it seems to set the wrong impression.

This is a follow-up issue to implement the decision taken on #2296557: [policy] Require PHP 5.5.

If you want to try to raise the requirement to PHP 5.6, please open a new [policy] issue to discuss that.

#2524432: Suggest PHP 5.6 as the recommended version

I just updated https://www.drupal.org/requirements/php to fix a bunch of general things and noticed the PHP 5.5 requirement for Drupal 8 was half on there; so I added to that (and removed some PHP 5.4 references also). But that and other pages still need a final update once this is committed, so adding that to the task list in the issue summary.

Adding a patch to work from for the 5.5.9 requirement.

Seems to be missing some changes from the patch in #1?

I couldn't get the patch from #1 to apply so did it manually, think I have them all now.

Looks good but the one remaining difference is that #1 changed the hash in core/composer.lock. I guess that still needs to happen, but could wait until this issue is closer to being ready.

The issue is running composer update to update the hash and php version in composer.lock is that it also updates all the dependencies.

Another fine reason to remove composer.lock and vendor from the git repo and get the packager to add them.

Another fine reason to remove composer.lock and vendor from the git repo and get the packager to add them.

No that is wrong. composer.json should be part of the repository in order to ensure that everyone uses the exact same version.

Composer.json should be in the repo, but composer.lock doesn't need to be. If specific versions of dependencies are needed the version should be stated in composer.json.

No it's quite standard practice to commit composer.lock to the repo as well (we've done it on client projects before), i.e. http://stackoverflow.com/questions/12896780/should-composer-lock-be-comm...

Other PHP frameworks don't commit composer.lock:
https://github.com/laravel/laravel
https://github.com/symfony/symfony
https://github.com/slimphp/Slim

But I agree I'd commit it to client projects.

If we ever move dependencies out of /vendor, then we'd want to ensure that, for example, the d.o packaging script and someone's local composer install get exactly the same versions of all the dependencies. Otherwise the likelihood of obscure and hard to reproduce bug reports due to version inconsistencies will go up immensely.

Either way, needs a new issue if people want to discuss this more.

Note that it would be nice to commit this after the next beta release, as I'm sure there are many people doing work with D8 on PHP 5.4.x environments (mostly because it's just worked up until this is committed, not necessarily because they chose 5.4 over 5.5). Then we should also make sure to broadly announce the increased requirement so developers don't get blindsided by the version requirement change.

I'm particularly interested since getting PHP > 5.4 on the Raspberry Pi (based on Debian 7) is a little tricky (this affects a couple projects like Drupal Pi and the Dramble), as it has to be compiled to work correctly on ARM at this time.

@geerlingguy - testbot runs PHP 5.4, I think that's the biggest blocker.

I hear it is possible to get PHP 5.5 on Raspbian, but it means upgrading to jessie.

Pure PHP frameworks don't commit their composer.lock. We're in a middle-ground so there's good arguments both ways; If we specify precise versions in composer.json (without the auto-upgrade markers) then it doesn't matter that much.

@timmillwood - True, if you do a dist-upgrade after adding jessie sources, you can get PHP 5.5, but there are other issues that make the experience annoying if you go that route. I've tried a few options (that included), and the simplest is to just compile PHP directly (this also allows for using later versions like 7.0.0 :).

And yes, I forgot testbot was still on 5.4, so no problem there. I think we should still make a point to announce this somewhere prominent, like core announcements on drupal.org/groups.drupal.org front page.

Considering that Drupal is so massive, I can't see how we could vouch for the stability of a release without providing the composer.lock, or doing what @Crell said with the versions.

@cilefen - then we need to make sure there is a way we can update something like PHP version in composer.lock without updating every dependency. The only viable option seems to be @Crell's comment "we specify precise versions in composer.json (without the auto-upgrade markers)".

Note that it would be nice to commit this after the next beta release, as I'm sure there are many people doing work with D8 on PHP 5.4.x environments

If the testbot blocker is solved before the next beta, I would argue that we should get this in before then as well, in order to get #2493911: Update guzzle, goutte and mink-goutte-driver to the latest release into that beta. Our critical queue is low enough now that it is theoretically possible (though by no means a certainty) that the next beta will be our last one, and having people running betas testing Drupal with an upgraded Guzzle prior to RC would be very nice.

As far as helping people who are currently running sites on PHP 5.4, I feel like running betas should mean that you're prepared for requirements changes at any time, and can choose to either update to the needed requirements or stay on an earlier beta.

I think a prominent announcement that this is coming is a great idea.

Left an enquiry with the DA about the status of PHP 5.5 bots here: #2467925-34: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1

+1 to a g.d.o/core announcement as the policy is accepted already.

#49: There are ways around to change composer.lock, there is for example a way to only update the lock (composer update --lock) or I once used a technique to move some things to require-dev from require).

That all can be done without having to not use a composer.lock.

Anyway: OT here, just saying the patch in here can be updated without problems.

@Fabianx - Thanks for the composer update --lock tip!

It looks like this is passing nicely on Travis CI with PHP 5.5 and PHP 5.6.

https://travis-ci.org/timmillwood/drupal/builds/70025990

Oh that is good to know, thank you @timmillwood

On https://www.drupal.org/pift-ci-job/1762 you can also see some mostly good history

Since our components do not yet have a lifecycle of their own, we should keep their PHP requirement in line with core.

Also, given that pifr/pift bots are ready to be migrated to 5.5 (per #2467925-35: [plan] Remove blockers to the "minimum viable" state of DrupalCI to ship Drupal 8 RC1), this is no longer blocked by DrupalCI.

+++ b/core/install.php
@@ -21,8 +21,8 @@
+if (version_compare(PHP_VERSION, '5.5.9') < 0) {
+  print 'Your PHP installation is too old. Drupal requires at least PHP 5.5.9. See the <a href="https://www.drupal.org/requirements">system requirements</a> page for more information.';

Any reason why we can't use the DRUPAL_MINIMUM_PHP constant here?

#57 the constant isn't available that early.

I think this might need a reroll?: https://dispatcher.drupalci.org/job/php5.5_mysql5.5/19/console

Rerolled because #2529082: Set better version for mikey179/vfsStream was committed in the meantime and it updated core/composer.lock.

testbot is still php 5.4

@timmillwood: no, we have a php 5.5 testbot. Please do not reset this issue.

Check out that green patch. We've upgraded the legacy testbots - They are currently running 5.5.26.

We're working on getting the dci containers going with 5.5.9.

You may 5.5 at will.

*censored* to the yeah! Thanks, Mixologic (and team)!

Wow, awesome! :D Thanks so much for the fast turnaround, Mixologic and crew!!

Committed and pushed to 8.0.x. Another critical bites the dust! YEAH.

Announcement posted to g.d.o/core here: https://groups.drupal.org/node/473473

Awesome, thanks all!

@mixlogix - sorry for the confusion, I guess you were too fast for me.

Now time to press on with #2524432: Suggest PHP 5.6 as the recommended version

No sweat @timmillwood : I should have communicated better that we were working on this, so thanks for being diligent.

Please somebody finish this remaining task:

- Update https://www.drupal.org/requirements/php, https://www.drupal.org/requirements, and any other drupal.org documentation that needs updating

The "main" requirements page shows "Drupal 8: PHP 5.5 or higher" yet.

I just edited it to say PHP 5.5.9 now.