- Issue created by @phenaproxima
- last update
9 months ago 765 pass, 2 fail - Assigned to tedbow
- Status changed to Needs review
9 months ago 2:02pm 13 December 2023 - Issue was unassigned.
- Status changed to RTBC
9 months ago 2:04pm 13 December 2023 - Status changed to Needs review
9 months ago 2:17pm 13 December 2023 - 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺
AFAICT this should update
ComposerPatchesValidator, unlesscweagans/composer-patches:2.xtruly is identical wrt API and safeguards. IOW: iscomposer-exit-on-patch-failuretruly everything that's needed? 😮 That'd be incredibly lucky! - Status changed to Needs work
9 months ago 1:48pm 18 December 2023 - 🇺🇸United States phenaproxima Massachusetts
Re #5: @cweagans confirmed on Slack:
The flag was removed in favor of always dying if the intended project state can’t be reproduced from the lock file.
So basically, we do need to update ComposerPatchesValidator to only require
composer-exit-on-patch-failurefor v1.x of the plugin. - last update
9 months ago 783 pass - Assigned to tedbow
- Status changed to Needs review
9 months ago 2:57pm 18 December 2023 - Status changed to RTBC
9 months ago 4:29pm 18 December 2023 - 🇧🇪Belgium Wim Leers Ghent 🇧🇪🇪🇺
#7++
I think this looks great. I contemplated two nitpicks: asking for a deprecation error when using
cweagans/composer-patches:^1(bad because disruptive for no good reason) or a@todofor removing the code for that version of the Composer plugin (but that's pointless: we should wait until that goes unsupported).So: ship it! 🚢
- Issue was unassigned.
-
phenaproxima →
committed f74d4daa on 3.0.x
Issue #3408483 by phenaproxima, Wim Leers: Support cweagans/composer-...
-
phenaproxima →
committed f74d4daa on 3.0.x
- Status changed to Fixed
8 months ago 1:47pm 10 January 2024 Automatically closed - issue fixed for 2 weeks with no activity.
