<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<div class="gmail_quote">On Feb 15, 2013 6:31 AM, "Anil Madhavapeddy" <<a href="mailto:anil@recoil.org">anil@recoil.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Core changing regularly at the moment is fine.  There aren't many<br>
third-party packages that depend on it, and we can establish lower<br>
bounds.  Note that the constraints aren't a long-term solution for<br>
compatibility, as you can't have multiple simultaneous library<br>
installations at present.<br>
<br>
The short-term annoyance is that all the dependent libraries are<br>
tied to Core versioning, and there is needless churn there.  For<br>
example, both Fieldslib and Comparelib had no substantial changes<br>
in 109.09.00 with respect to 109.08.00:<br>
<a href="https://github.com/janestreet/comparelib/commit/b4b36651591d3ebfb970bd22cca8daa803bca93b" target="_blank">https://github.com/janestreet/comparelib/commit/b4b36651591d3ebfb970bd22cca8daa803bca93b</a><br>
<br>
The biggest impact for this is felt with type_conv, which invariably<br>
results in a complete recompilation cycle.  I'd be interested in how<br>
you feel about independent versioning of some of these libraries<br>
in the longer term.<br>
<br>
-anil<br>
<br>
<br>
<br>
On 15 Feb 2013, at 03:17, Yaron Minsky <<a href="mailto:yminsky@janestreet.com">yminsky@janestreet.com</a>> wrote:<br>
<br>
> Right now, the Core suite of libraries changes a lot --- we have a new<br>
> release of everything every week.  The changes on a given week are<br>
> small, but there are always changes.<br>
><br>
> I can imagine this being something of a problem for OPAM.  If packages<br>
> specify specific revisions of the Core suite, then we're going to have<br>
> a massive version mismatch problem, where no two libraries can agree<br>
> on the version of Core that they need.<br>
><br>
> I have no obvious ideas as to how to solve this.  Does anyone else<br>
> have ideas?  Should we simply encourage packagers to specify a<br>
> lower-bound constraint on the Core libraries?<br>
><br>
> y<br>
> _______________________________________________<br>
> Platform mailing list<br>
> <a href="mailto:Platform@lists.ocaml.org">Platform@lists.ocaml.org</a><br>
> <a href="http://lists.ocaml.org/listinfo/platform" target="_blank">http://lists.ocaml.org/listinfo/platform</a><br>
><br>
<br>
</blockquote></div>