RFC Adoption of an official PHP release support policy

[maxime-rainville]

Proposal

From December 2021, Silverstripe CMS will drop support for end-of-life PHP versions in the next Silverstripe CMS minor release.

In practice, this means that Silverstripe CMS 4.10 (due in December) would drop support for PHP 7.1 and 7.2 and Silverstripe CMS 4.11 would drop support for PHP 7.3 around March 2022.

Background

Historically, we’ve only dropped support for PHP versions when an external factor has made it impractical for us to keep supporting it:

• Travis making it impossible to run builds against that PHP version
• webonyx/graphql-php dropping support older PHP release, which would have foreclosed further GraphQL development.

This was manageable when new PHP releases were far and few between. However, since PHP 7.0, new PHP releases are an annual event and are only supported for 2 years. Those new PHP releases will remove some deprecated APIs, but otherwise upgrades are pretty easy.

Many of the libraries we rely on have adopted a similar frequent-release-easy-upgrade model and have aligned their support timeline to the PHP one.

This is making it increasingly impractical for us to provide extended support for EOL PHP versions because we have to choose between supporting the old PHP version or allowing the latest version of some library to be installed. This has led us to weird decisions like forking PHPUnit.

It’s also not clear what class of Silverstripe CMS projects benefit from this approach. It’s difficult to imagine a scenario where a developer is desperate to run the latest Silverstripe CMS minor, but also comfortable running an outdated PHP version.

This also allows the use of new PHP features that are progressively released in new PHP minor versions.

Dropping support for EOL versions of PHP will bring us in line with other PHP libraries such PHPUnit.

Core modules in lock step will have the minimum version of PHP defined as a requirement in their composer.json files, even if there’s nothing with the module that actually requires the version of PHP. This is done to reduce confusion, and also to encourage developers to update their version of PHP so that they can upgrade to the latest version of Silverstripe CMS.

Context

We need to enable PHPUnit 9 support in the Silverstripe CMS 4.10 release as that will officially support PHP8. PHPUnit9 only supports PHP 7.3 and higher. PHP8 does not This would involve re-writing all our unit tests to be compatible with PHPUnit 9 API only. This approach requires us to drop support for PHP7.1/7.2 because we wouldn’t be able to run unit tests for those versions anymore.

This led us to rethink our wider approach to PHP support versions.

Read the PHPUnit 9 spike for more detail.

Pull request

• DOC Update PHP support policy #10122

[maxime-rainville]

^ @silverstripe/core-team Can we get some feedback on this?

[maxime-rainville]

@brynwhyman was asking if we would immediately update composer.json files to explicitly require a supported PHP version. The alternative would be to drop the test coverage for EOL PHP versions, but not restrict installation on older PHP versions.

My preference would be to explicitly block installation of new minors on unsupported PHP versions. Allowing installations would be giving people a false promise ... even if one version of a module was still working with the EOL PHP version, there would be no guarantee that a follow up patch release would not use a newer PHP API that would suddenly break things. It would be very easy for this to happen, because our builds won't run against that older PHP version so we wouldn't notice if we broke something.

If someone wants to install Silverstripe CMS on a EOL PHP version, they have the option to run composer install --ignore-platform-req=php or composer install --ignore-platform-reqs. At least this way, they are explicitly acknowledging this risk.

[michalkleiner]

Thinking about the use case we currently go through updating 4.8 installs to run on PHP 7.4.

We can relax our project PHP constraints from 7.3.* to 7.3.* || 7.4.* and run composer update on both versions of PHP to see if the installation will work on both at the same time. We can then release to the existing 7.3 environment and request PHP update to 7.4 while the site is not affected.

If we were limited to using 7.4 only, we would need to organise platform update at the same time, increasing the planning and handling effort a bit. It's also possible it wouldn't work the first time for whatever missing module reasons requiring further assistance in environments where we don't have direct control of things like SCP or CWP.
Agencies/vendors also may not have the opportunity to use the --ignore-platform-reqs switches.

From this perspective I'd vote for being strict with the tests support, but not as strict towards project code/runtime requirements.

[chillu]

Thanks for outlining the tradeoffs @maxime-rainville! The driver for this appears to be to reduce maintenance burden. I don't see this achieved by "soft limiting" the supported PHP version, and prefer your suggested approach of a composer constraint. PHP version deprecation has years of prior notice, which should be sufficient time for any projects to plan their upgrade paths.

@michalkleiner I hear your concern about the lack of self-service for (former) CWP In-Nation, and the difficulties to coordinate CMS and PHP upgrades alongside each other. I think the pathway forward there is to increase self-service in the hosting platform, although I can't speak for the provider of those platforms any longer :) On balance, composer PHP version constraints are standard practice in the PHP community.

[maxime-rainville]

I'm calling the RFC accepted. I'll update the docs accordingly.

[maxime-rainville]

I've got a PR to update the doc with the new policy. #10122

[emteknetnz]

@maxime-rainville Have approved PR, feel free to merge if you're happy with feedback from others

[maxime-rainville]

We've merged the docs ... we'll be publishing a blog post to highlight this change soonish