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

[Alain Frisch]

OCamlPro's opam builder ( 
http://opam.ocamlpro.com/builder/html/report-last.html ) really needs to 
be more advertised and its UI a bit polished to encourage people to 
actually look at it.  Also a report per maintainer (with emails sent 
automatically?) could be useful.

The release cycle is certainly important for this matter, and I hope the 
new policy (smaller and more regular releases) will help significantly. 
Simply announcing the next release date (ans sticking to it) sends a 
signal to package authors about when they should start checking their 
code works with trunk.  Of course, smaller releases also make it simpler 
to update the code and less risky to upgrade to for larger organization 
(and thus packages maintained by them are more likely to be fixed 
quickly). Hopefully the 4.03 experience was a bit exceptional (increased 
development pace, very long release, moving release date, breaking 
changes in the last months).

There is certainly things to learn and do to minimize the breakage of 
ppx and their consequences.  Introducing abstraction/compatibility 
layers should help (either things such as Ast_convenience.Constant in 
ppx_tools, or more ambitious stable APIs over the Parsetree).

It would also be interesting to understand in more details the reasons 
of the breakages for so many packages in 4.03.  It'd be a tedious work 
to collect this information, but it will probably guide both core 
maintainers and the community on how to improve the process.  There are 
two really important pieces of information:  which changes in OCaml 
cause the more breakage, and which broken packages cause the more 
transitive breakage.

I've to say that I'm also a bit scared by the inflation of dependencies 
across packages, including for relatively core packages that could 
themselves potentially block many others.  It's not because OPAM makes 
it easy to depend on external packages that it's always a good idea to 
do so.  As an example, see 
https://github.com/ocsigen/js_of_ocaml/blob/master/opam, and this does 
not account for transitive dependencies, which include e.g. oasis (whose 
own dependencies are themselves a bit scary).  More atomic packages 
could help in some respect (e.g. a package with only the js_of_ocaml 
compiler, with precompiled menhir parsers, could only depnd on cmdliner, 
I guess).  Same for ocamlnet (which is still not available for 4.03, and 
probably causing some further breakages;  if it were split into smaller 
packages, at least some of them should work on 4.03 already).



Alain


On 29/06/2016 18:40, Gabriel Scherer wrote:
> 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?
>
>
>
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>