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

[Hendrik Boom]

On Fri, Jul 01, 2016 at 09:10:28AM +0000, Fabrice Le Fessant wrote:
> 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.

I'm told that that is how Debian thought they could organise things.  
But they discovered that they also needed a  testing repository.  I'm 
not sure why, but I think it had to do with unstabe being, well, too 
unstable.  Packages mgrated from unstable to testing after a week with 
no serious bugs appearing aginst them, but nly after their dependencies 
had also migrated.

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

> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform