Composer 2 RC2 is now in the wild and the official release of 2.0 is quickly approaching:
The current plan is to release a 2.0 final before [the] end of October.
This is exciting for anyone who has complained about Composer’s performance in the past as Composer 2 brings significant performance improvements.
While developers will need to run composer self-update to opt-in to 2.0 locally, environments where the installation of Composer is scripted may end up on 2.0 surprisingly quickly after its release. This may prove to be problematic if you are using Composer plugins that need to be upgraded/marked as compatible with 2.0. Below are some options for you to prepare early for Composer 2 or hang back on Composer 1 a bit longer while you resolve any issues.
Remaining on Composer 1 Until You are Ready to Upgrade
If your project is using plugins that are not ready for Composer 2.0, and you want to stay on 1.x until you confirm compatibility, adding the following step after you install Composer will keep you there even after 2.0 becomes the default for new installations.
composer self-update --1Upgrading to Composer 2 Now
If you have validated that any Composer plugins you are using are compatible with 2.0 and want to test that ahead of its official release, add the following step after you install Composer. This will ensure that you upgrade to 2.0 now, and will have no effect once 2.0 is officially released.
composer self-update --2Specifying a Composer Version in Composer
If you are using an environment where you use Composer to install Composer (it sounds crazy, I know) such as platform.sh and you want to actively control the Composer version that is being used, either as an early adopter to 2.0 or to hang back on 1.x, you can specify your version requirement as a PHP build dependency. Refer to your host’s documentation for exact syntax.
dependencies:
php:
composer/composer: '^2.0@rc'