Please tag a stable release for Composer 2 support

[greg-1-anderson]

dev-master works fine with Composer 2 (c.f. #313, #309). It would be nice to have a tagged release so that sites using Composer 2 did not need to use the dev version.

[cweagans]

I'm not sure I'd call Composer 2 support "stable" just yet. #330 just landed 6 hours ago. I'd like people to try it out in a "real" environment a bit more before tagging a release in case there's anything else that needs to change. Composer 2 isn't at a stable release yet, so I'm not in a big hurry to rush 1.7.0 out the door at this point. Is there something I'm missing that's driving the urgency of this?

As an aside, you probably shouldn't be using master at this point. 1.x is where most people are at this point. master is where 2.0.0 is being developed.

[greg-1-anderson]

I don't know when Composer 2 stable will be released. At this point I am trying to clear any blockers in required dependencies (i.e. anything that example-drops-8-composer uses) because I want to make the case that the Pantheon docker images should be updated to use Composer 2 and only Composer 2 once it is stable. That conversation won't happen in earnest until the stable Composer 2 release is shipped, but, depending on when that happens, there might not be a lot of time to discuss, convince and decide.

So, while it is certainly not necessary to tag a release off of 1.x six hours after Composer 2 support is merged in, it would be nice to have a release in advance of Composer 2.0.0, and it's helpful for internal tracking purposes to have GitHub issues for our blockers.

[cweagans]

Definitely happy to help with that effort however I can. @nerdstein is testing with Composer 2 on Simplytest.me at the moment and I know there are a few others in other issues that are actively testing out Composer 2 support as well. Let's wait for some feedback for a short period of time and then we can move this forward. If something changes upstream, we can always tag another release.

cc @hussainweb @danepowell @staabm @rodrigoaguilera @mxr576 @clxmstaab @sun @balsama @mxr576 @Ayesh @samdark @nerdstein -- if some or all of you can let us know whether or not Composer 2 support is working in your environment, I'd feel a lot more comfortable with a tagged release in the very near term (especially if you have a mix of Composer 1 and 2 environments at the moment).

[clxmstaab]

my initial tests did not trigger new issues. it seems to work for me.

[cweagans]

@clxmstaab Using composer 1 or 2?

[clxmstaab]

Using composer 1 or 2?

both

[rodrigoaguilera]

I was using @hussainweb fork of composer-patches with composer 2 rc1 for some days without issues.

I only used it with composer 1 to confirm it was working

[danepowell]

I tested both Composer 1 and 2 as part of #330, assuming that feature branch was up to date then the 1.x branch should also be good.

[balsama]

Here's a recording of installing Acquia's minimal project with both Composer1 and Composer2. I made the following changes to Acquia's minimal project:

1. Switched constraint for cweagans/composer-patches from ^1.6.0 to 1.x-dev
2. Added some patches from acquia/lightning's composer.json file

Everything worked swimmingly 👍

[mxr576]

Earlier, besides the lack of Composer 2 support in this package, I also had an issue with Composer 2x itself which has proven to be a bug: composer/composer#9079
I'll try to find time to test both fixes next week.

[mxr576]

Did a quick test with the latest Composer 2x commit and the latest commit here and the result was the expected one. The same true for Composer 1.10.13.

[hussainweb]

I have been using both composer 1 and 2 to regularly test my repo here and it is working well.

[jacobsaw]

I have tested with both 1 and 2, no issues found. Ran a clean install with no cache on multiple Drupal projects that were created from drupal/recommended-project.

[cweagans]

Thanks for your help with testing and getting Composer 2 support in place, everyone! 1.7.0 is out!

https://github.com/cweagans/composer-patches/releases/tag/1.7.0