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

[Fabrice Le Fessant]

On Fri, Jul 1, 2016 at 9:19 AM Alain Frisch <alain at frisch.fr> wrote:

> On 30/06/2016 17:09, Fabrice Le Fessant wrote:
> 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).
>

Actually, one of my plans when creating opam-builder was to output a list
of versions that would be compatible for a small set of packages (the
platform), and create an opam-repository with only them, i.e. it would be
the equivalent of Debian stable while the standard repository would be
Debian unstable. Clearly, we currently under-use the information that is
available in opam-builder.


> 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?
>

About that part of the discussion, I am really against any additional
constraint that would delay a release of OCaml. We waited for years before
deciding to have a regular release schedule (every 6 months), and now,
everybody tries to delay releases for various reasons. So, yes to more
monitoring of the compatibility of platform packages with trunk and
beta-releases, but no to delaying the release because of platform packages
being late to meet compatibility.


> Do you have a description of OPAM-builder current strategy?


Everything is on Github:
Opam-Builder: http://github.com/OCamlPro/opam-builder
OPAM fork: https://github.com/lefessan/opam/tree/2016-03-02-opam-builder

For the strategy, it is the same as OPAM's standard strategy, i.e. it tries
to match your query while minimizing the number of installed packages.
That's the reason why it prefers `ppx_deriving.3.3` to `ppx_deriving.4.0`
(that have an additional requirement to `result`). As a side note, as there
are more and more meta packages (i.e. whose build/installation cost is
null), we should clearly change that strategy to (1) add an installation
cost in every package (`1` by default, `0` for meta-packages) and (2) try
to minimize installation cost instead of number of packages.

--Fabrice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20160701/babc194e/attachment.html>