Suitecrm: Require PHP 7.2 for SuiteCRM 7.12/8.0

[connorshea]

I've mentioned this in Gitter a few times, but I wanted to make an issue to allow for a more formal discussion. I guess this can be considered an RFC?

What I want to propose is this: For the next major/minor release of SuiteCRM (whether that is 7.12 or 8.0), we only support PHP 7.2 and above.

There are a few things I want to bring up as examples of why we should do this:

• The latest version of Sentry's PHP SDK requires at least PHP 7.1.
• PHPUnit 7 requires at least 7.1, and PHPUnit 7 is only supported until February 2020. We're currently stuck on PHPUnit 4 until we drop PHP 5.5. This is only going to get worse as time goes on, and I'm sure we're going to suffer a lot in the process of upgrading the test suite.
• PHP 7.1 is only supported with security updates until December 1, 2019, which is in under two months.
• We have had a number of problems with being unable to upgrade dependencies due to our wide range of supported PHP versions, and I anticipate (and already see, e.g. with PHPUnit) similar problems with 5.6, 7.0, and even 7.1 as we go forward. (It's probably also worth taking a look at my reasoning and examples in #7463)

The reason I want to skip ahead is because I don't think it's worth letting users use insecure versions of PHP at a significant cost of the project's development speed. (I know Debian backports security patches, but there's no guarantee everyone is using the version with backports from Debian, and Debian only backports on a 'best-attempt basis'. Plus, having a third party maintain the security patches seems a bit risky to me).

We supported 5.5 for so long that we can no longer run it in CI because Chrome dropped support for the only Ubuntu version on Travis that supports PHP 5.5 out of the box. Our PHP 5.5 support has also caused problems with upgrading Codeception, adding a PHP linter to CI (php-cs-fixer), keeping a bunch of other dependencies up-to-date, and prevents us from using any improvements made to the language since 5.5.

Hopefully, we'll never have to drop support for a PHP version in the middle of a minor/major release cycle if we begin requiring a more aggressive PHP version.

I can't say for sure right now what the impacts of supporting PHP 7.0 or 7.1 would be down the line (well, other than the Sentry SDK 2.0 not supporting PHP 7.0, Symfony 4 not supporting PHP 7.0, and being unable to upgrade to PHPUnit 7/8), but I'm certain in my prediction that there will be many more examples of problems.

I think allowing only the currently-supported versions of PHP when a given major/minor release of SuiteCRM comes out is a perfectly reasonable policy, and one that's followed by (as far as I can tell) Laravel and Symfony. Wordpress recommends PHP 7.3 for its latest release (although, it does support as low as 5.6). MediaWiki currently requires at least 7.0, and will require 7.2+ in 1.34 (which releases in January, I think?).

If we support SuiteCRM 7.12 for 2.5 years (which is how long 7.10 will be supported, as far as I can tell), and it releases in December 2019, we'll be supporting it until June 2022. By then, I assume PHP will have gotten at least 3 more releases out, and _even PHP 7.3_ will have had security support dropped (in December 2021).

Whether we like it or not, the greater PHP community is going to pull us forward. Rather than resisting, I think we should try our best to embrace it.

Thanks for coming to my TED Talk.

[Abuelodelanada]

I completely agree!

[pgorod]

I guess I also agree that when we "force" people away from PHP 5.x, we might as well "force" them directly into 7.2. There's no additional cost, I believe. And the advantages are many, as some TED speakers have emphasized.

Some libraries find it easier (or more necessary) to deprecate old versions than we do (e.g. Elastic Search, where I think we badly need an update that requires at least 7.0). And this ends up also pushing us in that direction.

And the truth is that this graph says it all...

Our user base should get more acquainted with the idea of upgrading PHP once every year or two. The old days of installing a server and leaving it unchanged ("to avoid getting into trouble") for years and years are gone...

[Dillon-Brown]

I guess I also agree that when we "force" people away from PHP 5.x, we might as well "force" them directly into 7.2. There's no additional cost, I believe. And the advantages are many, as some TED speakers have emphasized.

Ehhh, I'm not too sure about that one. From looking at the backwards-incompatible changes, while I don't see it being very likely that someone upgrading from 5.5.9 to 5.6.x would have any problems, upgrading from 5.5.9 to 7.2 and above would be pretty major. I'm guessing there is a ton of customisations (Store plugins too) that would need to be re-written to be made compatible.

[Mausino]

Maybe it's time to collect some anonymous data for better decisions to the future

4823 Anonymous Usage Statistics

@Dillon-Brown SalesAgility should have some picture of statistics about it (php versions) from service SuiteCRM:OnDemand, Migrations and Consultancy and Implementation Projects

[connorshea]

Ehhh, I'm not too sure about that one. From looking at the backwards-incompatible changes, while I don't see it being very likely that someone upgrading from 5.5.9 to 5.6.x would have any problems, upgrading from 5.5.9 to 7.2 and above would be pretty major. I'm guessing there is a ton of customisations (Store plugins too) that would need to be re-written to be made compatible.

I agree it probably won't be a seamless upgrade, but no matter what we'll have to rip off the band-aid eventually.

[tsummerer]

I fully support this.

[connorshea]

PHP 7.1 is now no longer supported with security updates as of a week ago :)

[gunnicom]

Hopefully it will be >=7.2 otherwise you have to push the verision again in a year.

[pgorod]

Maybe we could rephrase our minimum PHP requirement as "the minimum still supported" by PHP org (whoever runs that, I don't know).

They're moving forward faster than they used to, if I'm not mistaken; we should accompany that. I know the current expectation (add-on developers etc) is for things to be very slow and delayed, but that needs to change...

Using a 3 or 4 year old PHP used to be a normal thing, but I don't think it is anymore...