Drop PHP 5.5 support in SilverStripe 4.0

[chillu]

PHP 5.5 has been End Of Life (EOL) since July 2016, meaning it no longer receives bugfixes or security fixes. Anybody running it is effectively on insecure software - see http://php.net/eol.php

According to packagist installs as of Nov 2016 PHP 5.5 and lower made up 27.29%. That's rapidly trending downward (-12% in 6 months): https://seld.be/notes/php-versions-stats-2016-2-edition

This is also not an isolated decision for our framework - we're increasingly relying on third party dependencies like Symfony, which are very unlikely to continue development on their releases for unsupported PHP versions. Case in point: We want to upgrade to PHPUnit 5.x, which was released 18 months ago, and dropped PHP 5.5 support back then already: #6704

I'm proposing that we drop PHP 5.5 for SilverStripe 4.0, which would make PHP 5.6 the minimum required version.

Please vote with 👍 if you are in favour of dropping PHP 5.5, or 👎 if you want to keep PHP 5.5 support. In this case, please add a comment clarifying why that's important to you.

/cc @silverstripe/core-team

[dhensby]

Can I make a wild suggestion and say we just support PHP 7.1+?

Previously I've been very conservative with my opinion on our supported PHP versions; I've pushed for greatest BC compatibility as possible.

However I'm seeing more and more that the latest versions of libraries, even in minor releases, are upping their minimum requirements to PHP 7. If we stick with PHP 5 we are going to limit our ability to make use of other libraries in the community that are moving into PHP 7 only territory.

[SpiritLevel]

If SS extends its support period for SS3.x/PHP5.3.3 then you will be freer to worry less about backwards compatibility: this would make those who don't yet have PHP7.1+ on their servers more comfortable knowing they can continue, supported, for a while longer with SS3.x/PHP5.3.3. It gives people more time to upgrade to SS4, both their sites and all the supporting modules. And, you can announce SS4 with a big splash, saying this version makes the jump to PHP7!

[chillu]

@dhensby Maybe make your case for that with a bit more data? E.g. PHP versions of different Unix distributions, surveying common shared hosting providers. Also, what benefits will PHP 7 get us in terms of new language features we couldn't use otherwise?

But yeah, it brings up a good point: We'll support SS4 for far longer (June 2020, https://www.silverstripe.org/software/roadmap/) than PHP supports the 5.x release line (Dec 2018, see http://php.net/supported-versions.php). As a compromise, we could pre-announce that we're dropping PHP 5.x support before dropping SS4 support? Or are we really expecting to write PHP 5.x code in 2020?!

[dhensby]

@chillu I'll take a look into the facts - ultimately I think most distros aren't going to be shipping 7.1 for a while but this is about not being left behind in terms of where the PHP community is heading.

The alternative is to have agree that minor releases can bump PHP versions as other libraries seem to feel is acceptable.

[xini]

@SpiritLevel PHP 5.6 is supported until 31 Dec 2018 (http://php.net/supported-versions.php), the same as SS 3.x (https://www.silverstripe.org/software/roadmap/). I think it makes sense to drop support of PHP 5 completely for SS 4 like @dhensby suggested. But I agree with you that "Full Support" for SS 3.x should be extended in that case.

[sminnee]

I'm uncomfortable about the idea of making it impossible to run a server that supports both ss3 and ss4.

[sminnee]

I think PHP 7.1+ is a good target for SS5

[dhensby]

Linux distro support:

Distro	Default PHP version	Testing repo	7.1 available from other repos
Fedora 25	7.0	7.1	yes
RHEL/CentOS 7	5.4	-	yes
Debian Jessie	5.6	7.0	yes
Ubuntu 16	7.0	-	yes

The main reason to skip 7.0 support is speed as it's faster, but there's also support for iterable types and Asynchronous Signal Handling, which would be great for any CLI commands we want to build. https://wiki.php.net/rfc#php_71

Doctrine is one library dropping php 5 support for their next minor release and we can expect this to happen more over time. If we lock into 5.6 without agreeing that we can bump up to 7 in one of our minor releases then we greatly inhibit our ability to take in bug fixes to libraries we depend on.

[chillu]

OK, new vote: Should we state that we'll support PHP 5.x in SilverStripe 4.x as long as it's supported by PHP itself (Dec 2018)? Please 👍 or 👎 on this comment.

Aside: Async processing will be important for performant GraphQL as well (the "data loader" concept), since you run multiple queries over one HTTP call, rather than relying on concurrent HTTP calls (which can then fan out to multiple database connections etc)

[sminnee]

Yeah I could live with PHP 5.6 support for 4.x being dropped from the first minor release after 31 Dec 2018, particularly if we announced it alongside the main release.

[Firesphere]

@sminnee, 5.6 and 7.x can run side by side just fine in my experience.

But that aside, I think it would be good to keep 5.6 support in 4.x, until 5 is also out of the majority of servers. Completely cutting 5 would drop adaptation, as it forces agencies to update to 7, which is quite an effort.

I support dropping <5.6 until 5.6 is phased out.

[chillu]

Thanks for your feedback everyone!

• Option A: 40 👍 , 0 👎 for dropping 5.5
• Option B: 12 👍 , 2 👎 for dropping 5.6 with the 4.0 release (and supporting PHP 7.1+)
• Option C: 10 👍 , 0 👎 for dropping 5.6 when PHP ends support (Dec 2018)

I think most core committers (who are most impacted by this decision in terms of maintenance effort) have voted for Option A or Option C - It's hard to tell since Github doesn't show the full list (flaw in our voting process?). Option B only had two core committer votes (@flamerohr and @dhensby, who suggested the option).

I've opened a pull request at #6718 which implements Option A and Option C.

PRs for other modules (note that not all of them have that requirement in composer.json)
silverstripe/silverstripe-asset-admin#401
silverstripe/silverstripe-cms#1763
silverstripe/silverstripe-graphql#82
silverstripe/silverstripe-admin#3

[chillu]

Discussed a bit with Sam and Damian, two points:

• I've snuck in a minimum PHP 7.1 requirement in my pull request, which wasn't properly discussed or thought through - reverted to 7.0
• 7.0 goes EOL in the same month as 5.6, so we're pushing for a generalised rule on this - new PR: Reinstate 7.0 support, clarify policy #6720. @silverstripe/core-team Can you please add your vote over at the PR?

[sminnee]

Removing "easy" label as this isn't appropriate for newcomers.

[sminnee]

Also — we've completed this, so closing ;-)