<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jul 1, 2016 at 9:19 AM Alain Frisch <<a href="mailto:alain@frisch.fr">alain@frisch.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 30/06/2016 17:09, Fabrice Le Fessant wrote:<br>
Testing only the latest version of each package would already be very<br>
useful.  As a matter of fact, it could even detect earlier some problems<br>
by restricting the universe only to latest version of all packages (see<br>
below).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Moreover, it could be interesting to define a subset of "strategic"<br>
packages that we should really be up-to-date on OCaml release dates.<br>
Wasn't it part of the "platform" project to define such a curated list<br>
of packages?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do you have a description of OPAM-builder current strategy?</blockquote><div><br></div><div>Everything is on Github:</div><div>Opam-Builder: <a href="http://github.com/OCamlPro/opam-builder">http://github.com/OCamlPro/opam-builder</a></div><div>OPAM fork: <a href="https://github.com/lefessan/opam/tree/2016-03-02-opam-builder">https://github.com/lefessan/opam/tree/2016-03-02-opam-builder</a></div><div><br></div><div>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`). <span style="line-height:1.5">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.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">--Fabrice</span></div><div><span style="line-height:1.5"><br></span></div></div></div>