opam-repo-ci
opam-repo-ci copied to clipboard
ocurrent
Automate repair of reverse dependencies when package updates introduce breaking changes
When a package is updated with an API-breaking change, reverse dependencies which specify their dependency on the package without an upper bound on its version number will break. A reasonable way to address these breakages would be to set the upper bound in the version constraints in these packages to the previously released version of the newly-updated package. I think it would be useful to have the PR suggest these changes automatically.
@mseri in response to https://github.com/ocaml/opam-repository/issues/23694#issuecomment-1518106351, what's the current process for fixing version upper bounds on revdeps? Is it more involved than just setting them to the previous version of the package being updated?
Yes, sometimes we detect implicit dependencies, for examples or implicit conflicts due to some other packages or conflicts with depopts. Some other times, if the previous release happened before the revdeps tests were introduced, we have to bisect the versions until we find where it happened.
There is also the lower bounds check which may issues (especially on packages that were not tested before its introduction)
@punchagan and I have discussed support for this kind of workflow as an extension to our ongoing work of factoring out the revdeps tests into a tool that can be run locally. The idea would be to support something akin to a --promote functionality that would respond to failing revdeps in with the addition of upper bound limits.
More recently, following a discussion with @pitag-ha, we've discussed support for semi-automating the process of submitting PRs to fix downstream packages, which would be an even nicer way to address breaking API changes (when feasible). This would amount to support for semi-automated "(sub)ecosystem migrations".
An lighter lift would be functionality that compliments the automated addition of upper-bound range with pings to maintainers alerting them of the breaking API change (via automated issue creation via supported forges, perhaps with a fallback to email).
