Update composer/composer version constraint to support Composer 2

[Ayesh]

Updates the composer.jsons composer/composer version to allow composer v2 as well.

Related to cweagans/composer-patches#309.

Thank you.

[coveralls]

Coverage remained the same at 100.0% when pulling b532b0f on Ayesh:composer2 into 064b8d8 on cweagans:master.

[cweagans]

Looking at it, I'm not sure this repo needs a composer version constraint at all. What do you think?

[Ayesh]

For the API compatibility, I think it's good to have a version set in. But it doesn't has to be composer/composer. We can perhaps pin to composer-api-version ^1 || ^2`?

As far as I remember, older PHP versions didn't care if the traits match the interface, but recent versions do. So if composer were to introduce a new version with API changes, this trait will break backwards compatibility. So I think it's good to have a version locked it just to be sure.

[staabm]

to use composer-patches with composer v2 - which was added with cweagans/composer-patches#309 - we would also need a new release of this package, with the merged changes.

[Kocal]

Hi, is there any news about tagging a new release?
ping @cweagans
Thanks!

[tristanbes]

All PaaS upgraded their composer to version 2, hence the "emmergency" there :) @cweagans

[cweagans]

You should definitely not be using any version of composer patches that depends on this plugin. Use 1.7.0.

[Kocal]

Oh you're right, we were looking at master branch.
Btw why the latest tag does not require this plugin but the master branch "re-introduce" it? That's weird no? 🤔

[cweagans]

1.x is the current stable release series and is on the 1.x branch that split off from master a while back . Master is 2.x. :)

[Kocal]

Oh alright. Thanks for you explanation! :)