[ocaml-platform] Does Core change too often?

[Malcolm Matalka]

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