[ocaml-platform] Does Core change too often?

[Yaron Minsky]

I'm suspicious that the separate versioning will buy us anything, and it
will certainly add complexity to our export process.  In particular, my
hope is that core will become a dependency for many projects, at which
point a weekly release of core will cause lots of churn at the build level
whether or not type-conv is changed.

As for core, the changes aren't massive or terribly churny, but core is
big, and something in it changes every week.  Most users could probably
jump forward five versions and compile cleanly without changing a line of
code.  Given that, I would think that defaulting to inequality constraints
would help a lot.
On Feb 15, 2013 6:31 AM, "Anil Madhavapeddy" <anil at recoil.org> wrote:

> Core changing regularly at the moment is fine.  There aren't many
> third-party packages that depend on it, and we can establish lower
> bounds.  Note that the constraints aren't a long-term solution for
> compatibility, as you can't have multiple simultaneous library
> installations at present.
>
> The short-term annoyance is that all the dependent libraries are
> tied to Core versioning, and there is needless churn there.  For
> example, both Fieldslib and Comparelib had no substantial changes
> in 109.09.00 with respect to 109.08.00:
>
> https://github.com/janestreet/comparelib/commit/b4b36651591d3ebfb970bd22cca8daa803bca93b
>
> The biggest impact for this is felt with type_conv, which invariably
> results in a complete recompilation cycle.  I'd be interested in how
> you feel about independent versioning of some of these libraries
> in the longer term.
>
> -anil
>
>
>
> On 15 Feb 2013, at 03:17, Yaron Minsky <yminsky at janestreet.com> wrote:
>
> > Right now, the Core suite of libraries changes a lot --- we have a new
> > release of everything every week.  The changes on a given week are
> > small, but there are always changes.
> >
> > I can imagine this being something of a problem for OPAM.  If packages
> > specify specific revisions of the Core suite, then we're going to have
> > a massive version mismatch problem, where no two libraries can agree
> > on the version of Core that they need.
> >
> > I have no obvious ideas as to how to solve this.  Does anyone else
> > have ideas?  Should we simply encourage packagers to specify a
> > lower-bound constraint on the Core libraries?
> >
> > y
> > _______________________________________________
> > Platform mailing list
> > Platform at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/platform
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130215/3f7c63e6/attachment.html>