Make a jump on supported PHP versions?

[rdalverny]

I've been asked recently to help with a moonmoon 9.0.0-rc install that was crashing on a PHP 8 server (small changes only were needed but breaking) and it's the reason for this post: to discuss the opportunity to make a jump in the PHP versions moonmoon supports.

• stable current versions of PHP are 7.4, 8.0 and 8.1 as of today (https://www.php.net/supported-versions.php);
• moonmoon supports a range from 5.6 to 7; 7.0 support ended entirely 3 years ago;
• some stats seem to suggest that PHP versions < 7.2 count for ~10% of deployments, and going down (https://blog.packagist.com/php-versions-stats-2021-1-edition/ even if that's probably skewed by install using composer only, and it may not either reflect moonmoon deployed range); which means that ~10%-and-growing can't host moonmoon at all (8.x) and ~70% we're not so sure (7.2+);
• moonmoon 9.0.0-rc breaks on 8.0 and some of the (syntax) fixes are not retrocompatible with 5.x (EDIT: actually, that may be more a matter of choosing the right dependencies versions; it's mostly caused by phpunit most recent versions relying on typing);
• it's entirely understandable that there are still old unsupported PHP versions around, supporting some moonmoon deployments; but it's also more than likely that those would then upgrade their hosting before upgrading their moonmoon (any upgrade from 5.x or 7.0 is way overdue).

So I'd suggest the following plan:

1. release 9.0.0;
2. tag a branch v9 for legacy support; we may backport changes there; does GitHub provide any stats for releases downloads?
3. move master to a 10-dev version focusing on supporting current stable PHP only (that is 7.4/8.x),
   • upgrade all composer dependencies,
   • adjust code to make tests pass again,
   • BUT keep the last 2/3 unsupported releases in the CI, unblocking - this way, we may accept/test for improvements, but not require them (7.3, 7.2, 7.1 in this case);
4. simplify/cleanup code base from retro compatibility code tied to older 5.x;
5. revise if we can replace some dependencies/code parts with more recent libraries (parsing? auth? other?);
6. (not necessarily in this order) move on with the open PR/issues.

A possible PHP support/version policy to write down could then be:

• keep the list of supported PHP versions as: the current stable ones + 2 previous ones;
• drop support for a version that has been end-of-life for more than 2 years;
• increase minor version at least when a minor PHP version is dropped (10.1 would become 10.2 when 7.4 is dropped);
• increase major version at least when a major PHP version is dropped (10.2 would become 11.0 when 7.x is dropped);
• revise once a year at least.

Writing down such a policy would also set more clear expectations regarding past and future versions support.

Does it seem decent to you for a start or any adjustment required?

[rdalverny]

I have yet to write down an explicit policy doc for this, but I made this change on my branch for this specific issue: rdalverny@81e974e (other fixes/changes on the same branch also, but those are separate issues).

[rdalverny]

More formal proposal to be added to README:

PHP Support Policy

On a best effort basis, trying to keep a review at least once a year:

1. moonmoon will support the stable current versions of PHP and the 2 previous stable versions (on January 2022, that means PHP 8.1, 7.4 + 7.3 and 7.2).
2. Support will end for PHP versions that have been end-of-life for more than 2 years (see https://www.php.net/supported-versions.php).
3. When support for a minor PHP version is dropped, moonmoon minor version will increase (moonmoon 10.1 would become 10.2 when support for PHP 7.4 is dropped).
4. When support for a major PHP version is dropped, moonmoon major version will increase (10.3 would become 11.0 when support for the last PHP 7.x is dropped).
5. Dropping support for a version does not mean that they will necessarily not run properly anymore moonmoon latest version.
6. But this defines a criteria for when arbitration is needed between updates required to support newer platform features/requirements, and keeping compatible with older versions.
7. Separate maintenance branches may be kept for major versions where some changes may be backported.