[opam-devel] [ocaml-infra] Dealing with incompatible releases in opam

[Daniel Bünzli]

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 ?  

Daniel