Future of Composer 1.x support?

[reedy]

#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]

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]

Ref #243