Update the documentation and testing matrix for current PHP releases

[stevegrunwell]

This pull request raises the minimum PHP version to 7.2, per the library's "Supported Versions" documentation.

Additionally, since no currently-supported HHVM releases support PHP 7, HHVM has also been removed.

Changes to the .travis.yml file include:

• Limit testing matrix to supported PHP versions and the nightly snapshot, but permit the nightly build to fail
• Prevent interactive prompts and prefer distribution versions of libraries when running composer install
• Until such a time that code coverage is being generated, disable XDebug in the CI environment (performance improvement)

With older PHP versions out of the way, I've also upgraded PHPUnit to version 8 (which requires PHP 7.2+) and made the necessary compatibility fixes to the test suite, which fixes #431.

[drewish]

@bhelx what are your thoughts on backwards compatibility with old PHP versions? we've tended to keep testing even on unsupported versions for a bit.

[bhelx]

Although technically these versions are not supported, we still have a lot of people who cannot upgrade from 5.6, quite a few in 5.5, and a handful of people using 5.4, 5.3, 5.2.
We also have a lot of people using 7.0 and 7.1. We like to try to keep them working for people.

At the least, I'd like to keep 7.1, 7.0, and 5.6. I think we're okay to remove the HHVM versions though as I can't find the actual use of these versions in our logs and I don't think we need to support it moving forward.

@stevegrunwell what would be the consequences of keeping an older version like 5.6 around?

[stevegrunwell]

First, I 💯 realize this gets into more of a business decision rather than something that I — as a customer + OSS contributor — get to weigh in on, but if an outside perspective helps:

• It requires some work, but it's possible to change the version of PHPUnit used in a per-environment basis (I'm happy to do that in this PR)
• Bumping the minimum version of PHP will prevent developers using Composer and older versions of PHP from getting the update; if Composer sees the environment is running PHP 7.0 but the new version of the package requires php: ^7.2, it will keep them where they are.
  • For example, the customers you mentioned who are still using PHP < 5.6 must either be manually installing the updated versions of the library or (more likely) still running older, unpatched versions of Recurly (changes since 15a227423, for reference)
  • However, this means that future bugfixes wouldn't be backported, and I'm guessing your team doesn't want the maintenance burden of manually backporting them.

Maybe a good middle-ground solution would be:

• Revert the bump in the composer.json file, taking it back to php: >=5.6
• Lower PHPUnit to version 7, removing the need for the : void return type hints on test fixtures (since return type declarations aren't available in PHP < 7.0).
• Introduce a simple compatibility layer for running tests written for PHPUnit 7 on earlier versions (essentially, if PHPUnit\Framework\TestCase doesn't exist but PHPUnit_Framework_TestCase does, define a new PHPUnit\Framework\TestCase class that extends PHPUnit_Framework_TestCase
• Restore PHP 5.6, 7.0, and 7.1 to the Travis testing matrix, but maybe mark them as allowed to fail since they're not officially supported?
• For versions of PHP that can't run PHPUnit 7 (e.g. PHP < 7.1), explicitly load the PHAR file in the test environment during the installation step.

As an aside, the fact that people are running Recurly — a billing service — on un-supported/unpatched versions of PHP seems like an opportunity for Recurly to help instill consumer trust:

• Using the logs referenced in this thread, identify customers running older versions of PHP.
• Notify those customers that are running outdated/insecure versions of PHP
  • On average, PHP 7.x runs about twice as fast as PHP 5.6 — better app performance means fewer resources required to run the customer's application
  • Available exploits in older versions of PHP could lead to their Recurly API keys being compromised, which may lead to fraudulent charges and put them at risk of violating section 4.E of the Recurly Terms of Service

[bhelx]

@stevegrunwell We greatly appreciate your pragmatism. I'd support the middle ground solution you outlined. I'd like to continue to run the PHP 5 tests even though we aren't explicitly supporting it.

As an aside, the fact that people are running Recurly — a billing service — on un-supported/unpatched versions of PHP seems like an opportunity for Recurly to help instill consumer trust.

Hey, we completely agree. We do run through our logs and capture stats on these things across all our customers. We try our best to get them to upgrade their systems, but for many of these businesses, they just don't have the resources or ability to upgrade. We've found it very hard to make these kind of arguments. Now that we have a team around Developer Experience though, I think we will be doing more of this in the future.

On another note, I wanted to point out that @douglasmiller has made some good progress on the v3 PHP client and it should be ready to test soon. Would you be interested in taking a look at it when it's ready? Since no one is using it yet, we can make sweeping changes to it and we're going to be looking for opinions from our customers using modern PHPs.

[stevegrunwell]

@bhelx PR has been updated to cover the middle-ground solution discussed.

Now that we have a team around Developer Experience though, I think we will be doing more of this in the future.

I wish them all the luck in the world 😄

On another note, I wanted to point out that @douglasmiller has made some good progress on the v3 PHP client and it should be ready to test soon. Would you be interested in taking a look at it when it's ready?

Absolutely, happy to help however I can!

[bhelx]

Thanks @stevegrunwell ! That was a quick turn around. Apologies for the late response on my end. Either me or Doug will shoot you an email when the code is ready. We will likely send out some comms to our other PHP customers.

[bhelx]

👍