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

[Xavier Leroy]

Dear platform fellows,

Many good points have been made already, so let me just add a few
remarks.

- I have the impression that OCaml 4.03 introduces more breaking
  changes than 4.02 did.  That could explain why OPAM packages are
  taking longer to be upgraded to 4.03.  I don't know what it means
  for the future: should the OCaml core team be more prudent with
  breaking changes?  should the packaging community get ready to
  handle even more breakage?

- As an upstream author of a few libraries, it's not obvious to me
  what the best / recommended way is to communicate with the packagers
  of "my" software, e.g. being informed of problem reports with the
  corresponding packages, or informing them of new versions of "my"
  soft.

- OPAM-wide continuous integration is great, of course.  Concerning
  computing resources:

> On Thu, Jun 30, 2016 at 11:09 AM, Fabrice Le Fessant
>     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.

What would it take to get, say, one full build every day?  I think we
could find some funds for that, e.g. from the Caml consortium.  After
all, a cool 12 cores / 24 threads blade server costs only 2.5 kEur or
so.

- Xavier Leroy