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 <[email protected]> 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 > [email protected] > http://lists.ocaml.org/listinfo/platform _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
