search

Ocramius / PackageVersions

:package: Composer addon to efficiently get installed packages' version numbers
MIT License
3.22k stars 67 forks source link

Add support for Composer 2.x #133

Closed Seldaek closed 4 years ago

Seldaek commented 4 years ago

As per https://github.com/composer/composer/issues/8726 - it'd be good to get popular plugins updated already to avoid blocking everyone later.

Ideally, you'd tag a new 1.4.3 release here so that people using PHP 7.1 and up get a chance to use Composer 2 in combination with this package.. In this case the old package versions won't be still usable as they'll break dependency resolution, so I hope this is enough reason for an exception. There is a composer2-1.4 branch on my fork which applies cleanly on top of 1.4.2.

Note that to run update with composer 2 you need to use --ignore-platform-reqs as dealerdirect/phpcodesniffer-composer-installer is also not updated yet.

Ocramius commented 4 years ago

Travis-CI has been broken all week, as it seems...

Ocramius commented 4 years ago

TL;DR: @Seldaek as discussed personally last week, I did indeed think long and discussed with others about whether to release or not support for composer/composer 2.0.0-dev for this package in the 1.4.x branch: in the end, I will not do it.

For other readers that may not get the full context: there are two sides to this, a technical one, and a political one.

My release policy is indeed very strict:

I didn't find a way to consider a bump to Composer 2.0.0 a "security issue" in the 1.2.x branch or 1.4.x branch, both still running on PHP 7.1.

That was the technical part.

The political is my unwillingness to do it, as I believe that the ecosystem continuously requires a push, and that's part of why I like maintaining the packages under the ocramius/ vendor: people using them are either lagging behind or get the best effort development quality that I can provide.

In general, I still believe that forcing (yes, I'm aware that I'm always pushing it) people to upgrade to latest stable is a much more viable strategy than trying to drag along people and mostly companies that are lagging behind.

I am aware that Packagist has an old API that will need to run for a lot of time (until composer 1.x is dead), but I would much rather see composer v2 to be 7.4+, instead of supporting every version that is still used in the wild: that's ultimately not my choice, and it is something we'll disagree upon.

This can still be supported in forks supporting older versions (heck, even PHP 5.3!), but won't be done under my watch.

kore commented 4 years ago

Actually exactly this caused installation errors on all freshly booting systems running on top of Frontastic right now. Our build process automatically updated composer and with the existing lock files of our customers the package versions cannot be resolved any more.

We right now force composer to stay at 1.4 because of this in all customer repositories because we also cannot update their dependencies without proper testing.

It would be great to allow composer 2.*. This would have saved us a lot time of hotfixing the build processes for all customers.

Seldaek commented 4 years ago

@Ocramius Just one last consideration here from my side. Of course you can have your fun with your ocramius/* packages, but as this is depended on by Doctrine, it means all Doctrine users are exposed to your policies without having chosen that at all.

Also note that I did not ask you to support PHP 5.3, but IMO 7.2 isn't that unreasonable to ask for these days. It's not even EOL yet. I know I have a bunch of servers still using it until later this month when I can move to Ubuntu 20.04 LTS and move to php 7.4 at the same time.

Anyway my composer2-1.4 branch shall remain there, in case you change your mind.

Ocramius commented 4 years ago

but as this is depended on by Doctrine

Irrelevant: I know thousands of other packages depend on this, which is the point of me pushing such agendas.

Anyway, closing+locking, as I'm not intending to change this.

Authoritative response remains https://github.com/Ocramius/PackageVersions/pull/133#issuecomment-609950991

Ocramius commented 4 years ago

We right now force composer to stay at 1.4 because of this in all customer repositories because we also cannot update their dependencies without proper testing.

composer/composer is at 2.0-dev-stage right now, not for GA usage on end-customer projects.

That goes back to #105 (see end of thread).