How to deal with opam revdeps (CI failure)?

Ecosystem
1

Hi, I’m preparing a new release of a package (camlp5), and there are “breaking changes”. Some of them are unavoidable, and so I’m wondering how I go about fixing broken packages that depend on camlp5. The changes are easy, and I can send PRs to all the packages in question, but

  1. revdeps seems to be checking against all versions of packages (e.g. elpi), and so it would seem that this would require changing packages that have already been shipped?

  2. obviously, the package-maintainers might want to take their time about upgrading to a new version of camlp5, and introducing #ifdef code just to allow a new release seems … overkill.

I think the right thing here is to just modify the opam files of all these packages that depend on camlp5, to specify that their dependency is “<= 8.00” so that they don’t work with this new release? And I guess I would do this in the same PR where I submit my new release?

[BTW, it’s an alpha release, specifically to work out these and other problems, all of this breakage is sort of expected.]

Is that the right way to deal with this?

2

You’ve got it right. For posterity, the process is typically:

  1. make PR on opam-repository

  2. use CI to check which rev-deps fail

    • if a breakage is expected, add a commit to add appropriate upper bounds
    • else, debug and potentially fix issues with release

  3. (optional & concurrently) send PRs upstream to rev-deps to update API changes