[ocaml-platform] Is it taking too long for OCaml software to become 4.03-compatible? Would release process changes help?
alain at frisch.fr
Fri Jul 1 08:19:24 BST 2016
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
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
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.
More information about the Platform