Yanick Witschi

Yeah, my `!regex:` solution has turned out to work perfectly fine for mulitiple projects. It's very simple and powerful.

Yeah I've added a custom step in my own context to do this and it works but it's actually a chunk of ugly code that would require polishing, testing etc....

I did some in-depth analysis of this PR (finally - sorry @driskell) and I'm fairly confident that the approach is actually correct! There's no point in marking the `replace` links...

@stof actually, your comment made me think about "why do we need `markPackageNameForLoading()` in https://github.com/composer/composer/pull/10410 but here we want to get rid of it for `replace` packages?". So I've incorporated...

🥳 by the way: you don't need to modify anything to log requests, it should be visible when running with `-vvv` 😊

@fritzmg this is the last one to close 4.13, do you still plan to document this? 😊

4.4 is EOL, there's absolutely no point in keeping our docs cluttered with version hints. I don't think people can expect us to maintain documentation of old versions. Otherwise, where...

Looks like cache control header handling should become its own class with an optional prefix. So you can work with multiple `CacheControl` objects, one having no prefix (default) and others...

If that RFC becomes a standard, then yes, Symfony should support having vendor specific cache control headers. However, we should try to keep the current API as simple as it...

Not really a new feature. The current implementation is broken. It will not add the required schema as described in https://github.com/symfony/symfony/issues/54406. Just faced the same issue and this PR fixes...