[ocaml-platform] Does Core change too often?

[Anil Madhavapeddy]

OPAM has a strong dependency on ocamlfind at the moment, which doesn't
support multiple library versions.  OPAM could be extended to support
multiple installations (since the constraint model expresses it fine),
but would need to understand more of the build process too.

There are some steps towards this already, such as the `.install` files
which automate binary installation/removal.  We were reluctant to put
any more in the first version in the interests of getting something out.

-anil

On 15 Feb 2013, at 11:21, Malcolm Matalka <mmatalka at gmail.com> wrote:

> Right now, I think Core not being afraid to change frequently is good.
> I'd rather have that than a stale API that kind of sucks.  And I'd hate
> to have the public Core get out of synch with what Jane St uses
> internally because it increases the overhead for you which decreases the
> chance of timely releases.
> 
> Multiple versions has not been a problem for me since I convert opam
> packages I'm interested in to Nix packages, and Nix handles multiple
> versions of installed packages just fine.  It's probably too late in the
> game for opam to have this style as well, I don't know anything about
> opam's design, but it's worked pretty well in Nix for me.
> 
> Beyond that, I think good semantic versioning is probably key.  If the
> majority of Core changes are backwards compatible (I have no idea if
> this is the case) then installing the right package for a lot of the
> apps probably isn't so bad.
> 
> /Malcolm
> 
> Yaron Minsky <yminsky at janestreet.com> writes:
> 
>> 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
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>