Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
At #3557585-63: Update to Composer 2.9.2 @andypost pointed out:
Sadly we need new issue to upgrade to 2.9.3 as it's a security upgrade https://getcomposer.org/changelog/2.9.3
This is the issue to do that.
Steps to reproduce
Proposed resolution
11.x / 11.3.x
https://git.drupalcode.org/project/drupal/-/merge_requests/14236 - Merged
11.2.x
TBD (composer/composer currently pinned to 2.8.9)
https://git.drupalcode.org/project/drupal/-/merge_requests/14238 if we want to bump to 2.9.3.
10.6.x
https://git.drupalcode.org/project/drupal/-/merge_requests/14237 - Merged
10.5.x
TBD (composer/composer currently pinned to 2.8.9)
https://git.drupalcode.org/project/drupal/-/merge_requests/14254 if we want to bump to 2.9.3.
Remaining tasks
- Decide what to do with 11.2.x and 10.5.x
- Commit MR 14238 to 11.2.x?
Commit MR 14237 to 10.6.x- Commit MR 14254 to 10.5.x?
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
TBD, probably need something?
Issue fork drupal-3565943
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
dwwOpened https://git.drupalcode.org/project/drupal/-/merge_requests/14236 with the trivial results of
composer update composer/composer. Let's see what the bot thinks...Comment #4
andypostThank you!
Comment #6
dwwThanks for the review!
I opened MR 14237 for the 10.6.x backport: https://git.drupalcode.org/project/drupal/-/merge_requests/14237
I opened a branch for the 11.2.x backport, but composer is pinned to 2.8.9 there. Not sure what's happening in that branch, and if we update dependencies like this or not. Tagging for RM review to confirm if/where we want this change backported.
Comment #7
dwwUpdating summary with links to MRs for each branch.
Remaining tasks including deciding what to do with 11.2.x and 10.5.x.
Comment #10
catchCommitted/pushed to 11.x and cherry-picked to 11.3.x
The 11.2.x branch didn't have a merge request yet, so I just added that.
edit: after doing that, I realised I hadn't properly read the comment above... doh.
Comment #12
catchMoving to active for the backport discussion then.
Comment #14
dwwThanks! Closed 14236, and made a few more updates to the summary for remaining tasks.
Comment #15
dwwMinimum changes to get
composer/composerto2.9.3on11.2.x:Resulted in a few more changes than I really wanted. I manually removed the
react/promiseline from the resultingcomposer.jsonso that we still just have it in the require section fromcomposer/composerinstead of a new root dependency.Pushed the results to the
3565943-update-composer-2_9_3-D11_2branch -- see https://git.drupalcode.org/project/drupal/-/merge_requests/14238.Comment #16
quietone commentedFor 10.6.x, I updated composer locally and my changes are the same as in the 14237.diff, with only index value changes. So, the 10.6.x MR is correct.
Comment #17
dwwThe 11.2.x MR is basically working now. Moving to NR for release manager review / sign-off / direction.
Thanks!
-Derek
Comment #19
dwwSo we have it if we want it, opened an MR for 10.5.x, too.
Comment #20
ghost of drupal pastThis is a very interesting moment since composer having learned nothing from the plugin fiasco released 2.9 instead of 3.0, deliberately breaking backwards compatibility with 2.8. Should this be forced on D10? I do not know but there should be ample warnings if you do this somehow perhaps release notes? and AFAIK at least Pantheon and Amazee needs a heads up since their build processes might include running composer during build and this most excellent composer version does break on both according to bug reports on composer which are obviously immediately shut down.
Comment #21
dwwRe: #20: that might all be true. However, this is only the dev dependency in the core composer.lock, not whatever version of composer might be in the PATH or otherwise in use by humans at the CLI, CI, deployment pipelines, etc.
Comment #22
quietone commentedSetting to RTBC for the 10.6 MR only.
Comment #25
catchYes #21 is correct this won't affect composer install/update at all.
I've gone ahead and committed the 10.6.x MR here.
I think the only question with 11.2/10..5 is whether we should do a bonus patch release for them (or roll the change into a security release if we need to do one), but we can probably commit them to the branches without deciding that - will wait to hear from other RMs though.
Comment #26
dwwCool, thanks. Updating summary to match current reality.
Comment #27
smustgrave commentedCorrect status?
Comment #28
dwwI don't believe so. It's already been ported. Now the release managers need to review and decide what to do with the open MRs. Maybe RTBC is more appropriate?
Comment #29
smustgrave commentedThat’s my mistake I got this confused with another ticket that was backported to all the above branches.
Comment #30
catchYeah RTBC is good here I think.
Comment #31
longwaveThe only reason to do a patch release that I can see is because of
drupal/core-dev-pinned.drupal/core-devdepends oncomposer/composer ^2.8.1so users can already upgrade their Composer to a secure version if they need to; I have a site running on 11.2 with core-dev and my Composer there is already at 2.9.3 thanks to dependabot.drupal/core-dev-pinnedon the other hand explicitly depends on 2.8.1 only.Given the work has been done we can commit this anyway, and then we can defer the decision about a release. No harm if it never gets released, and we will be ready if we do decide (or are forced) to make a release.
Comment #35
catchCommitted/pushed to 11.2.x and cherry-picked to 10.5.x, thanks! As @longwave says we can worry about how/if to release later.