Allow adding to a released version conflicts

[shyim]

When a dependency package / PHP extension update is released and contains a breaking change, the package maintainer that depends on that package gets a lot of support requests because of the problem.

The issue can be resolved by adapting the new stuff or introducing a conflict, which can only be added in a new version.

So my suggestion here is to allow adding afterwards conflicts to already released versions, in that way package maintainers can configure this for wide range of versions and don't get a lot of support.

There are user-land approaches to handle this, like contao/conflicts: https://github.com/contao/conflicts
which works but cannot be used together with tags, so you cannot set different conflicts for different versions.

Real-world issues that could be solved easier:

• Breaking change with 6.1.0 after 6.0.2 phpredis/phpredis#2562

Such things often happen: https://github.com/contao/conflicts/commits/main/, which would make the life of package maintainers easier.

The change to Packagist itself would be straightforward. It would let the user manage the conflicts and merge the additional conflict data with the data in composer.json. So, an actual code change would be required, as only the metadata in Packagist matters.

What do you think about such a change in Packagist?

[Seldaek]

I definitely see the value in this, but I am not 100% what the consequences are in terms of getting this new conflict data to users. I think it should work fine if you do a full update, but if you do a partial update in composer then you might miss the data and end up running into issues still. I don't think it's killing the feature, just saying that it may not work in all cases like you imagine.

But yes I think it'd be worth considering a way to do this, at least adding conflicts or perhaps also narrowing down requirements.

[stof]

This also means that Packagist needs to store separately the metadata extracted from the VCS repository (where the VCS data is the source of truth) from overrides applied in Packagist, so that overrides are not lost next time the package is updated from the VCS repository.
This would probably also require to have some info in the UI about the fact that some metadata has been overridden, to avoid confusion when comparing the Packagist metadata and the composer.json file (which is also relevant if a project decides to register the repository as a VCS repository instead of using the Packagist metadata).

And I think that such feature should be restricted to released versions. Applying overrides to dev versions would be a lot more confusing as we would have to decide how they behave when the dev version updates its metadata. Anyway, a dev version is a moving target, so the conflicts can be applied directly in the VCS repository in for them, which is much better.