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

[Gabriel Scherer]

Dear platform,

TL;DR: I propose that we change the OCaml release process to remain in
"beta" stage while there remain OPAM packages that are broken by the new
releases and their version bounds have not been updated.

I'm a bit frustrated with the time it takes for the OCaml ecosystem to
catch up with the 4.03 release -- which has been released two months ago
now, on April 25.

A large chunk of my personal hacking time following the release was spent
on updating Batteries, with a 4.03-compatible release happening on May 12,
so two weeks after the release -- a time I would still consider too long
for our downstream users waiting to try the 4.03 goodness but held back by
a Batteries dependency. I recently helped make atdgen compatible with 4.03
(it's a dependency of IOCaml for example), and just today found out that
Coq releases (or its CoqIDE part) did not work on 4.03 (with no upper-bound
in opam, it would just miscompile).

I find it frustrating because that means that there is a large time window
where we advertise (externally, to beginners, etc.) that the best OCaml
versions ever is 4.03.0, while running opam from this switch to install any
major software whatsoever feels like playing a rigged russian roulette. I
feel bad whenever I'm informed that my software (or anyone else's, in fact)
does not work by end-users that would rather have spent their day doing
something else than trying broken software.

Do you agree that this is a problem? What could we do to fix that?

When I started writing this email I intended to send it to Damien Doligez,
as the release manager of the compiler distribution, with the following
suggestion: maybe we could have a *much longer* beta-testing period for
OCaml versions that would be used not (only) for finding bugs in the new
version, but also to let important pieces of the ecosystem update to the
new version. Say, at least a month. We could have a fixed set of software
that we monitor, or in fact all of what's in OPAM, and delay the release
until they get updated/fixed or their OPAM version bounds get fixed. (Aha,
a Platform indeed!)

Does that sound like a reasonable idea to you? Should we monitor all OPAM,
or only a subset?

This suggestion is rooted in the idea that when we announce the release to
our end-users, stuff should just work -- or refuse to install itself. Maybe
this is an old idea of the SVN times and we're now in the era of
continuously-released, always-broken stuff?

Finally, there has been all this work on the "OPAM weather services",
continuous build of opam packages etc., plus the work that Damien is doing
around release time. It doesn't seem to have worked very well for 4.03. Who
is monitoring this stuff? Do we need to fix them to make them work better,
or to fix our process to use them better? To be honest, I'm never looking
at these services -- I just don't think of using them. Can I get an email
whenever they detect that my stuff is broken? Say I'm a new package
manager, are there guidelines somewhere on what the best practices are and
what I should do?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20160629/254d9258/attachment.html>