wikimedia / composer-merge-plugin

Merge one or more additional composer.json files at Composer runtime
MIT License
926 stars 160 forks source link

Future of Composer 1.x support? #212

Open reedy opened 3 years ago

reedy commented 3 years ago

210 is partially related.

While there's no real reason to break Composer 1.x support straight off, it'd be useful knowing a roadmap of upstream composer 1.x support and knowing what to do... Especially if continuing to support 1.x and 2.x simultaneously becomes an issue

https://blog.packagist.com/deprecating-composer-1-support/

mcaskill commented 3 years ago

With a bit more planning related to bumping from 1.4 to 2.0, I think we could have cut Composer 1 off then.

Once we do get decide to break away from Composer 1, we will probably have to rename the namespace to V3 to account for the methods that will be purged (like PluginState::isComposer()).


I don't know if this helps timeline-wise, but Seldaek published this blog post today:

[…] Composer 2.0 was released in late October 2020. We hinted in the release announcement that Composer 1.x was pretty much EOL […] First of all we realized in the past few months that 1.x will probably take years to fully go away. […]

Reduced v1 metadata API update rate starting in May 2021 […]

Restricted access to unused packages via the v1 metadata API starting in May 2021 […]

— 2021-02-25 blog.packagist.com

And this is from the original blog post:

Composer 2.1 might still come with PHP 5.3 support, depending on the timeline and which features end up being included, but then at the latest by Composer 2.2 we will drop support for everything older than PHP 7.1.3.

— 2020-10-24 blog.packagist.com

reedy commented 6 months ago

Ref https://github.com/wikimedia/composer-merge-plugin/issues/243