[opam-devel] [ocaml-infra] Dealing with incompatible releases in opam
daniel.buenzli at erratique.ch
Thu Mar 27 15:17:10 GMT 2014
Le jeudi, 27 mars 2014 à 15:53, Anil Madhavapeddy a écrit :
> So it should indeed have a direct react dependency in its OPAM file (to ensure that the optional Lwt dependency on react is picked up, thus ensuring Lwt_react is available).
Maybe in that case but still, in fact through `include M` directives in signatures a package may leave its API definition to a package it depends on so you could have:
p1 <- p2 <- p3
with p3 formally and morally only depending on p2.
So for an incompatible release of p an overapproximation of the rule is
For every p' that depends on p and has dependents in the repository,
introduce an upper bound whether p' builds fine or not.
A more refined rule would be
For every p' that depends on p and has dependents (and recursively)
in the repository that break, introduce an upper bound whether p' builds
fine or not.
> I don't believe any new releases should be necessary for libraries that compile fine now, aside from updating constraints in their OPAM files.
Taking the rule above, since I had to constrain p' even if it was building fine with p I will have to make a new release (or rather say a new package name) for escaping the constraint no ?
More information about the opam-devel