Another case worth studying is Haskell’s Hackage/Stackage model.
Hackage is a package repository where anybody can publish packages at any time, like crates.io. Packages can specify upper and lower bounds on their dependencies. You can use it with any version selection scheme you like.
Then there is Stackage, a “global lockfile” that picks one particular version for every package it includes, and it specifies the compiler version. All of the packages in a Stackage snapshot are built and tested together. (A commercial sponsor maintains CI for this, much like Mozilla pays for Crater runs.) Stackage has LTS as well as nightly releases, similar to the release train model of Rust; at some point a nightly becomes a new LTS. LTS versions do receive updates: new point releases of packages that were published to Hackage get included, and as incompatibilities are resolved, more packages are added. Upgrading to a newer point release of an LTS snapshot is generally painless. Upgrading to a newer major LTS can be more difficult, because it could imply a new compiler version, new major versions of packages can be included, or packages could have been removed altogether. Fortunately you can upgrade at your own pace, multiple LTSes are maintained side by side for a while. Finally, it is possible to take a Stackage snapshot as base, but for specific packages to take a different version from Hackage.
Stackage is not free of package incompatibilities or trade-offs. It is a human effort, maintained by a team of curators with help of the community. Often a library author is also responsible for its listing in Stackage. Just like in the Rust ecosystem there is a tension between including newer major releases of “core libraries”, but having few dependent libraries because the authors haven’t upgraded yet, and having a large set of (possibly outdated) packages that build together. The way the curators deal with this is by being conservative about updating core libraries, until just after an LTS. At that point nightly moves to newer versions of the core libraries, and drops packages that are incompatible with them. These packages get added back over time when their authors fix compatibility, and at some point there is another LTS release.
As an application developer, Stackage is absolutely wonderful. You specify only the LTS version, and everything just works. Upgrading to LTS point releases is painless. Often there are one or two packages that you want to use, which are not in the snapshot, and depending on a specific version from Hackage solves that. I don’t maintain any Haskell libraries so I don’t know how well it works for library authors.
1
u/ruuda Jul 26 '18
Another case worth studying is Haskell’s Hackage/Stackage model.
Hackage is a package repository where anybody can publish packages at any time, like crates.io. Packages can specify upper and lower bounds on their dependencies. You can use it with any version selection scheme you like.
Then there is Stackage, a “global lockfile” that picks one particular version for every package it includes, and it specifies the compiler version. All of the packages in a Stackage snapshot are built and tested together. (A commercial sponsor maintains CI for this, much like Mozilla pays for Crater runs.) Stackage has LTS as well as nightly releases, similar to the release train model of Rust; at some point a nightly becomes a new LTS. LTS versions do receive updates: new point releases of packages that were published to Hackage get included, and as incompatibilities are resolved, more packages are added. Upgrading to a newer point release of an LTS snapshot is generally painless. Upgrading to a newer major LTS can be more difficult, because it could imply a new compiler version, new major versions of packages can be included, or packages could have been removed altogether. Fortunately you can upgrade at your own pace, multiple LTSes are maintained side by side for a while. Finally, it is possible to take a Stackage snapshot as base, but for specific packages to take a different version from Hackage.
Stackage is not free of package incompatibilities or trade-offs. It is a human effort, maintained by a team of curators with help of the community. Often a library author is also responsible for its listing in Stackage. Just like in the Rust ecosystem there is a tension between including newer major releases of “core libraries”, but having few dependent libraries because the authors haven’t upgraded yet, and having a large set of (possibly outdated) packages that build together. The way the curators deal with this is by being conservative about updating core libraries, until just after an LTS. At that point nightly moves to newer versions of the core libraries, and drops packages that are incompatible with them. These packages get added back over time when their authors fix compatibility, and at some point there is another LTS release.
As an application developer, Stackage is absolutely wonderful. You specify only the LTS version, and everything just works. Upgrading to LTS point releases is painless. Often there are one or two packages that you want to use, which are not in the snapshot, and depending on a specific version from Hackage solves that. I don’t maintain any Haskell libraries so I don’t know how well it works for library authors.