Composer: PHP support strategy

Created on 14 Apr 2020 · 55Comments · Source: composer/composer

(Following-up from https://github.com/composer/composer/issues/8759#issuecomment-613642026)

When it comes to supported PHP versions, should we:

[ ] 😕 Ship multiple phar files with different dependency versions for different min-PHP versions. This has the potential to be messy when people report bugs, and it means we still need to support PHP 5.3+ in Composer so overall not great.
[ ] 🎉 Skip to 3.0 directly after the 2.0 release and drop PHP versions there. Easier on maintenance for us, but it causes a mess for all plugins which would need to be adjusted again to support 3.0.
[x] 👍 Drop older PHP versions in 2.1, but do not make any refactorings of signature to use new language features. That'd be a good compromise maybe to keep BC in signatures for now but be allowed to modernize internally a little bit at least. Old PHP users can still use 2.0.x which would be supported as far as bugfixes are concerned.

You can vote in reactions if you care either way.

Question

Source

Seldaek

👍68 🎉32 😕3

Most helpful comment

Makes sense to you but for me I don't want to keep supporting packagist.org composer-v1 format forever, so I want everyone to get to v2 ASAP, it's actually less work to support 5.3 in composer v2 than to support everything around v1 forever. This is anyway not the topic of this issue, it's been decided ages ago. The question is how we go forward after 2.0..

Seldaek on 19 Apr 2020

👍7 😕2

All 55 comments

* Skip to 3.0 directly after the 2.0 release and drop PHP versions there. Easier on maintenance for us, but it causes a mess for all plugins which would need to be adjusted again to support 3.0.

Well, does it actually require bumping the plugin-api-version ? (avoiding confusion in the ecosystem might be a reason, if composer 3.0 ships with the plugin-api version 2 too)

stof on 17 Apr 2020

Also, do we already have features in place in the composer install and the self-update command to account for required PHP version (so that a phar does not self-update itself to a new version not compatible with your PHP runtime) ? If no, this must be implemented first.

stof on 17 Apr 2020

👍2

Well, does it actually require bumping the plugin-api-version ? (avoiding confusion in the ecosystem might be a reason, if composer 3.0 ships with the plugin-api version 2 too)

Yes it does IMO, if we keep everything BC to keep the plugin-api version to 2, there is no need to bump the version to 3.0. That's the 👍 option.

Also, do we already have features in place in the composer install and the self-update command to account for required PHP version

Yes that's been part of it since the beginning.

Seldaek on 17 Apr 2020

🎉1

Which versions are you planning to drop? Would be good to have a 2020 version of https://seld.be/notes/php-versions-stats-2018-1-edition to see in which environments composer is used currently.

cebe on 17 Apr 2020

According to https://blog.packagist.com/php-versions-stats-2019-2-edition/ - and given that's already almost six months outdated, I'd say a PHP 7.2 or 7.3 target would be reasonable. Or possibly 7.4 if it's worth it, because I don't want to be dropping versions too frequently, and regardless 2.0 would need to be bugfixed for a while still.

Also depends on when we reach 2.0 stable and so on.. That's just my opinion now.

Seldaek on 17 Apr 2020

👍1

7.2+ sounds reasonable, not too cutting edge, but so far in line with also many frameworks and libraries and what their current minimum is. Usually the security-fixes/EOL timeline is a good conservative measurement probably ( https://www.php.net/supported-versions.php ).

dereuromark on 19 Apr 2020

What minimum PHP version you plan to support with 2.0? Sorry asking, but I can't find a definite roadmap.

AnrDaemon on 19 Apr 2020

@AnrDaemon 2.0 will support 5.3 to make sure everyone can migrate.

Seldaek on 19 Apr 2020

That makes no sense. Whoever want to migrate, could install last 1.x version first, ensure compatibility, then upgrade to 2.x.

I was expecting 7.0 or 7.1 as a minimum, honestly.

AnrDaemon on 19 Apr 2020

What you say makes no sense for people who are stuck on PHP versions lower than 7.

Seldaek on 19 Apr 2020

👍2

I'm stuck on that myself with one project. And it makes perfect sense to me to support objectively better minimal language version with a new major application version.

AnrDaemon on 19 Apr 2020

Seldaek on 19 Apr 2020

👍7 😕2

My apology. I did not mean to come out that rude.

Answering your question directly, I think it would be understandable to have 2.0 as "maximum backward compatible version", and start tightening the bolts in 2.1.

AnrDaemon on 19 Apr 2020

Skip to 3.0 directly

Would this option require updating the composer-plugin-api version number? If the signatures of the interfaces included in that "package" remain the same, the update would be easier (b/c non-existent) for plugin devs? If that's the only concern, this would be the cleanest solution, I guess, as you could do "proper" SemVer to the outside?

franzliedke on 21 Apr 2020

If we don't want to break/bump the plugin-api, it means we have to keep things so similar that there is no point in calling it a 3.0 IMO.

Seldaek on 21 Apr 2020

Oh, okay. Thanks for the feedback.

@Seldaek Can you list (or link to an existing place) which parts of the codebase would benefit from newer language features (beyond syntax sugar)?

franzliedke on 21 Apr 2020

Nope sorry I don't have that kind of free time atm :) Mostly it's syntax/stricter typing, a few places would benefit from dropping weird workarounds for 5.3 limitations, and the biggest gain is finally being able to update all dependencies to more modern versions. For the latter at least PHP 7.2.5 would be needed IMO so we can upgrade to Symfony 5 components and that gets us LTS for many years again. I don't see a huge gain in going to 7.3 or 7.4 aside from a couple nicer syntax things.

Seldaek on 21 Apr 2020

👍5

That's useful enough already, thanks for clarifying, and taking the time. :hugs:

Okay, so I guess the plugin API does encompass enough interfaces / classes (at least transitively) that its version would need to be bumped, too. Will vote for 2.1 then.

franzliedke on 21 Apr 2020

Or possibly 7.4 if it's worth it, because I don't want to be dropping versions too frequently

If the 2.1/3.0 have to be supported for another 8 years, I think 7.4 is reasonable. otherwise I suggest to target the majority (maybe 7.2+) at this stage and bump to 8.0+ later since 8.0 introduced a lot of things.

jhdxr on 25 Apr 2020

@jhdxr yup that's what I'm tending towards as well. It doesn't have to be 8 years no ;)

Seldaek on 26 Apr 2020

I would not go to 7.4+ yet, given that PHP 7.3 is still actively supported.

And given that the primary gain will be to update dependencies (mostly Symfony ones), going 7.4+ will not give much benefit compared to going 7.2.5+ or 7.3+.

stof on 27 Apr 2020

👍2

Agreed.

As much as I approve of pushing modern version usage forward, I also think that it's not a job for low-level dependencies (and Composer is about as low-level as it gets). IMHO, those should strive to remain as broadly compatible as possible - within reasonable limits, obviously. Use new features where you strongly benefit, but not for the sake of it.

franzliedke on 28 Apr 2020

😕1 👍1

What about a more conservative approach? Raise the supported PHP version to PHP 5.6 and PHP 7 in Composer 2.1 for now, and gradually increasing the required PHP version by dropping support for that PHP version about 2 years after the EOL of that PHP version.

This means that for any new PHP version, Composer will support it for about 5 years, which prevents a situation where users of LTS software can't run the same version of composer on both their old machine and the new machine, before updating to a new version.

Ubuntu 16.04.1 shipped with PHP 7.0 and is still supported by Canonical, and many will upgrade directly to Ubuntu 20.04.1 (4-year cycle)

This would mean PHP 8 would be the only supported version starting in 2025, and PHP 5.6 support will run until at least 2021

At the same time, this system prevents having to support both PHP 5.6 and 8.0 at the same time, since PHP 5.6 support will be dropped when PHP 8.0 is going to be supported.

alexanderpas on 15 May 2020

@alexanderpas bumping to PHP 5.6+ rather than PHP 7.1+ means that composer won't be able to upgrade the bundle dependencies to Symfony 4, but will need to go to Symfony 3.x only (which is supported only until november 2020)

stof on 15 May 2020

Symfony 3.4 is a LTS version recieving security fixes until November 2021.

This means the expected EOL of the Composer 2.1.* series supporting PHP 5.6, and the EOL of Symfony 3.4 would be at same time, under the plan suggested in my post above.

See also: https://symfony.com/releases

Meanwhile, the next composer version after that (2.2?/3.0?) would only support PHP 7.1+ and would therefor be able to use Symfony 4.

alexanderpas on 15 May 2020

@alexanderpas The end for security fixes is IMO not that much of interest here, but the fact that Symfony 3.4 will not get bugfixes after November anymore.

xabbuh on 15 May 2020

There's literally no reason to support PHP5 going forward, given the drastic changes in language as it is.

I've raised the same question in smarty-php/smarty#593 , and most of the arguments applied to Composer as well.

AnrDaemon on 15 May 2020

👍1

IMO for composer 2.x i would expect PHP 5.6 and higher to be supported.
Then in some years in a composer 3.x+ i would expect PHP 7.0 and higher to be supported.

There are still many distribution releases that run PHP 5.6 or lower and are still supported.

I don't think you should be going against the long term support of distributions which are used not only on personal projects, but also from small scale companies to large scale enterprises and government institutions. Upgrades take time because software and user applications and projects need a lot of review and changes and money put into it, particularly when they are very customized.

Ubuntu: https://wiki.ubuntu.com/Releases

Ubuntu 20.04 Focal - ESM not set with PHP 7.4
Ubuntu 18.04 Bionic - ESM April 2028 with PHP 7.2
Ubuntu 16.04 Xenial - ESM April 2024 with PHP 7.0
Ubuntu 14.04 Trusty - ESM April 2022 with PHP 5.6

Debian: https://wiki.debian.org/DebianReleases

10 Buster - EOL LTS not set with PHP 7.3
9 Stretch - EOL LTS ~2022 with PHP 7.0
8 Jessie - EOL LTS ~2020-06-30 with PHP 5.6

CentOS / RHEL: https://wiki.centos.org/About/Product

CentOS 8 - EOL Maintenance 2029-05 with PHP 7.2
CentOS 7 - EOL Maintenance 2024-06 with PHP 5.4
CentOS 6 - EOL Maintenance 2020-12 with PHP 5.3

These EOL service means these distros get security updates at least till those dates, meaning the systems are supported and secure by concept, so they are embraced by its users who have no reason to upgrade to newer systems, unless there is a radical change in software, which they won't consider likely for composer.

As you may note in these documentation pages, PHP 5.4-5.6 wont go anywhere until at least 2024 for CentOS and PHP 5.6 as well not before 2022 for Ubuntu.

Sury provides additional PHP packages for Debian and Ubuntu - https://deb.sury.org/
Remi provides additional PHP packages for CentOS and RHEL - https://rpms.remirepo.net/

With those community non-official supported repos (which not all enterprise policies will allow) we can get PHP 5.6 across the board for all major distros on old releases.
But we can't expect that for PHP 7.0+.

lpalgarvio on 28 May 2020

👎2 👍2

I don't think you should be going against the long term support of distributions which are used not only on personal projects, but also from small scale companies to large scale enterprises and government institutions. Upgrades take time because software and user applications and projects need a lot of review and changes and money put into it, particularly when they are very customized.

I don't think we should look at the versions those distributions include. They have their own resource to support these out-of-date php. We should look at which version the majority of modern frameworks/tools/libraries still support.

phpunit: 7.2+ by 2021 Feb
symfony: 5.5+ by 2021 Nov, then it jumps to 7.1+
codeigniter: 5.6+ EOL not specified. new version targets 7.2+
yii: 5.1+ by 2020 Dec 5.4+ for _Next release_ +2 years

These EOL service means these distros get security updates at least till those dates, meaning the systems are supported and secure by concept, so they are embraced by its users who have no reason to upgrade to newer systems, unless there is a radical change in software, which they won't consider likely for composer.

If you are someone who really care about security, but you are still running old distributions version without updating php interpreter, it's highly possible that your framework will not get any updates, even security fix.

jhdxr on 28 May 2020

With the option to go with dropping older PHP in 2.1, how will someone download the newest version of composer for PHP 5.3. Currently we have self-update --1 and self-update --2, but we are missing a way to say "latest widest compatible version".

GrahamCampbell on 4 Jul 2020

@GrahamCampbell I think it's easy to fix. A runtime version check can be added into the installer.

jhdxr on 5 Jul 2020

@jhdxr That's not going to be a correct solution if there are multiple versions of PHP installed on the same machine, and only one copy of composer. Any one of them could be used to run self-update.

GrahamCampbell on 5 Jul 2020

@jhdxr That's not going to be a correct solution if there are multiple versions of PHP installed on the same machine, and only one copy of composer. Any one of them could be used to run self-update.

If you are running multiple php on the same machine I suppose you should have multiple composer instances as well. just like python+pip vs python3+pip3.

jhdxr on 5 Jul 2020

👍2

if there are multiple versions of PHP installed

…then you know what you are doing and prepared to deal with consequences.
IMHO

AnrDaemon on 9 Jul 2020

2.0 would need to be bugfixed for a while still

Do you have a sense of how long? Do you intend to support it until 2024-06 to accommodate the full lifecycle of PHP 5.4 on CentOS 7? If so, are you confident you'll be able to keep making those bug fixes work on PHP 5.3 for that entire timeframe as well? If not, it might be worth considering dropping at least PHP 5.3 from 2.0, since there'll be no Linux distro still maintaining PHP 5.3 beyond 2020-12, and it seems likely that Composer 1 will need to be supported until at least then anyway.

With the option to go with dropping older PHP in 2.1, how will someone download the newest version of composer for PHP 5.3. Currently we have self-update --1 and self-update --2, but we are missing a way to say "latest widest compatible version".

Maybe it makes sense to add the concept that 2.0 is an LTS release, and therefore add self-update --lts as an option?

[For Composer 2.1] PHP 7.2 or 7.3 target would be reasonable. Or possibly 7.4 if it's worth it, because I don't want to be dropping versions too frequently

I think 7.2 is the best target for that, since Ubuntu 18.04 will maintain that until 2028, and you'll probably want to stop supporting Composer 2.0 well before then. I don't think you'd get any benefit in setting 2.1's minimum below 7.2, since no Linux distros provide extended support for 7.1, ZendServer's LTS of 7.1 ends on 2023-01, and Ubuntu 16.04's support of 7.0 ends on 2024-04, which are all before CentOS 7's EOL of PHP 5.4. Meanwhile, relative to PHP 7.1, 7.2 gets you Symfony 5, which even if you don't upgrade to in Composer 2.1, you'll be able to in a later minor without changing PHP requirements and get an extra 2 years of lifetime from that.

CentOS 8 - EOL Maintenance 2029-05 with PHP 7.2

CentOS 8 introduced app streams, so PHP 7.2 will be retired from there in 2021. So once CentOS 7 is EOL, only Ubuntu will remain in providing outrageously long support for outdated PHP versions.

effulgentsia on 12 Aug 2020

Maybe it makes sense to add the concept that 2.0 is an LTS release, and therefore add self-update --lts as an option?

Running composer self-update on a PHP 5.3 runtime will already stay on releases compatible with them.

stof on 12 Aug 2020

Looking at the current Composer usage stats (CI excluded), I am thinking 7.1 for Composer 2.1 would be a good choice. It leaves ~8.5% of installs stuck on Composer 2.0, but hopefully that will be even less by the time we get to a 2.1 release anyway.

7.2 can come later on, the main advantage of requiring it would be to be able to upgrade symfony components to 5.x, but an upgrade to 4.x will already bring us tons of cleanups and fixes/features. At the language level 7.2 is not that interesting, so IMO not worth dropping an extra 8.5% of installs who're using 7.1 still.

Seldaek on 11 Sep 2020

👍5

PHP 7.1 would be great for us at Heroku, since the heroku-18 stack offers 7.1 or later, so we'd offer Composer 2 for that stack only, knowing we wouldn't have to break anyone on the older stacks by first giving them 2.0 and then not updating anymore (those older stacks are EOL/deprecated, but still).

dzuelke on 17 Sep 2020

@dzuelke actually, the whole point of doing the PHP version bump in 2.1 rather than 2.0 is precisely to allow migrating to 2.0 everywhere, so that packagist.org can at some point remove support for the old metadata format (which is less efficient both for composer and for packagist).

stof on 17 Sep 2020

The metadata format isn't really a concern, since a push to Heroku only installs from the lock file, @stof.

I mainly want to ensure that a project last composer updated will work well into the future (that's our "erosion resistance", although obviously it's less of a concern for builds, but still).

If you generate a 2.0 lock file that requires 7.0 today (these projects exist, I'm sure), and then git push heroku master that in the future when 2.1 is out, we'd have to have extra logic to keep these older projects on 2.0, which at some point won't receive updates anymore.

If instead we make Composer 2.0 available on heroku-18 and later only, then 7.1 is the oldest available version anyway, and we don't have to worry about folks getting stuck on 2.0 once 2.1 is released.

Does that make sense?

dzuelke on 17 Sep 2020

I don't think it makes sense @dzuelke. If a project used Composer 2 to generate the lock file you should really run Composer 2 to install it or you may have problems with plugins requiring Composer 2, or the project relies on some Composer 2 runtime stuff and you would be skipping it. Likewise if it was built with Composer 1.

Composer 2.0 is going to be available to PHP 5.3+ as of Composer 2.0 and should be supported everywhere. Composer 2.1 will require 7.1 most likely yes, so on heroku-pre-18 you could still upgrade to Composer 2 where possible IMO, but especially should where it was used to build the lock file. And on 18+ you should follow the lock file.

Composer 2.0.x will be supported way longer than 1.x.

Seldaek on 18 Sep 2020

Sure, but 2.0.x will still be EOL eventually, right? Ubuntu 16.04, which is the base for our heroku-16 stack, has extended security maintenance into 2024... ;)

Hence the idea to support Composer 2 on heroku-18 and later only where the minimum PHP requirements for Composer 2.1 will not be a problem.

Ah well, we will see. Nothing set in stone.

dzuelke on 18 Sep 2020

I guess the idea is that 2.0 and 2.1 would be EOLed at the same time as each other?