Add support for Composer 2.x #133
Conversation
|
Travis-CI has been broken all week, as it seems... |
|
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 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 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 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. |
|
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. |
|
@Ocramius Just one last consideration here from my side. Of course you can have your fun with your 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 |
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 #133 (comment) |
That goes back to #105 (see end of thread). |
As per composer/composer#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.4branch 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-installeris also not updated yet.