[ocaml-platform] Is it taking too long for OCaml software to become 4.03-compatible? Would release process changes help?

[Alain Frisch]

On 30/06/2016 17:09, Fabrice Le Fessant wrote:
> The reason why OPAM-builder cannot monitor trunk is by design: to
> achieve almost real time on a 4-core computer for 5 versions of OCaml,
> opam-builder makes an extensive use of caching binary installations of
> dependencies. This cannot be done on a moving target like trunk, where
> you would have to recompile all packages (all versions, sometimes with
> different depends because of depopts) at every commit in the trunk,
> after clearing the cache. That's the reason why I only do it for
> official beta releases, and opam-builder takes two or three days to
> compile the repo.

Testing only the latest version of each package would already be very 
useful.  As a matter of fact, it could even detect earlier some problems 
by restricting the universe only to latest version of all packages (see 
below).

Moreover, it could be interesting to define a subset of "strategic" 
packages that we should really be up-to-date on OCaml release dates. 
Wasn't it part of the "platform" project to define such a curated list 
of packages?

Do you have a description of OPAM-builder current strategy?  I found out 
yesterday that a simple "opam install ppx_type_conv" would fail on a 
clean 4.03 switch, because the latest version of that package compatible 
with 4.03 depends on ppx_deriving with no upper bound constraint, and 
OPAM chooses to install the latest version of ppx_deriving which turns 
out to be incompatible with that version of ppx_type_conv.  But 
OPAM-builder did not report any error for that version of ppx_type_conv: 
it picked an older version of ppx_deriving (which works fine).  I'm 
wondering if this is because of a different solver configuration, or a 
deliberate (or not) consequence of OPAM-builder strategy.


Alain