There are a couple questions in the comments about LTS Haskell and related projects, I was thinking this might be a good summary. (tel's might be better, but I had already written this so I'll let others decide https://news.ycombinator.com/item?id=8834823)
Hackage is the core package server, comparable to RubyGems.
The Stackage (http://www.stackage.org/) project functions like a CI system for Hackage. Stackage builds and tests the group of packages that have opted in to it, ensuring that the latest versions all work together (when there's an incompatibility between packages, the authors of the packages are pinged to resolve the issue [1]).
When a build of all the packages succeeds, Stackage generates a "snapshot", a list of all the package versions used for that build (sort of like a Gemfile.lock/Podfile.lock, for the whole ecosystem). Developers can have Cabal (Haskell build tool) use the package versions from that list when installing new packages. This ensures that when you install a new package that it's compatible with the other packages you're currently using.
The issue with those snapshots (generated nightly) is that you'll want to get updates for your packages, but the snapshot generated N days from now might have packages that have made breaking API changes, making them incompatible with your application.
LTS Haskell attempts to fix that. It's based off a specific Stackage snapshot. For the duration of the LTS (currently 3 months), the major versions from that snapshot are locked down, but patches/bugfixes will continue to be released. This allows you to get bugfixes for your application while still getting the advantages of Stackage.
[1] As an example, when the language-ecmascript 0.17 package was released, the authors of the 2 packages that depended on language-ecmascript < 0.17 were pinged to update their packages: https://github.com/fpco/stackage/issues/390
I guess this is similar to Quicklisp for CL packages? A stable "world snapshot" every now and then instead of rolling releases.
I works pretty well in the CL world, I think this approach (releases) will become standard for package management in Ecosystem-package-managers (as it has been in the OS world).
Hackage - live packages get uploaded and released fast
Stackage - a rolling tested release. It promises that all packages will compile together. (There are a few flavors of this).
and now LTS Haskell. A snapshot of Stackage that doesn't roll very quickly (every 3 months). It won't do upgrades to packages at all, except for bug fix & patch releases. So your own application code can pull down the LTS today, and again tomorrow, and be relatively sure that everything will work the same.
Haskell's package repository, Hackage, changes very rapidly. The best policy that exists today for determining whether packages will work together, the Package Versioning Policy, is a bit like Semantic Versioning. This allows you some chance in hell of finding compatible packages, but it's very low information and often fails. This is exacerbated by a few things
1. Due to static typing package combination errors are detected at compile time not runtime. This means that potential mismatches in package versions are detected and punished very early and very severely. This is why Cabal compares so disfavorably to NPM. It's not that NPM is more advanced, it's that Cabal tries harder to ensure that package mismatches don't survive build.
2. There are differences in opinion on the right place to put burden of package matching—should the maintainers exhaustively test things and maintain accurate and complete information at all times? Or should people just tell them quickly when things break. Unfortunately, these two methods of handling versioning don't live together nicely and they wreck havoc for the solver.
3. Haskell as a language strongly promotes chunking off nice, trustworthy abstractions and squirreling them away into their own package. This means that there are a lot of packages all versioning against one another and the package matching problem is quite large.
So, atop this a few "curated sets" have been built which push the package managing troubles to someone else---namely a build farm where, arguably, it ought to be. These sacrifice bleeding edge availability for a bit less personal burden finding compatible package sets. The two I use are called Stackage and Nixpkgs.
Stackage is in particular supported by the company FPComplete and FPComplete sells Haskell solutions to industry. They are therefore well-interested in providing a support solution for stable sets of packages from Stackage. This may even just be a formalization of what they already do since they probably cannot justify code breakages to customers as "well, the state of the art of libraries keeps changing".
As far as I can tell these LTS package sets are stable points in the master package set which will receive bugfixes and unquestionably unbreaking feature updates alone. In terms of the PVP, they can receive minor version bumps but are protected against major ones. Stackage is a rather massive set of packages, so this is done in a pretty conservative manner and it seems reasonably experimental at the moment.
In particular, it'll come down to the willingness of library maintainers to backport bugfixes to prior major versions of their libraries. Good library maintainers have support windows they care about already, but not everyone has the resources to pull that off. LTS will feel this differential effect.
Anyway, hopefully that's a good, reasonably correct overview. Corrections welcome.
My best understanding from the posting is that it's going to be a "stable" version of the "Haskell Platform" set of packages.
Haskell has been notorious for moving (too?) fast while not maintaining decent backwards/forwards compatibility, a problem made worse by some tooling issues ("cabal hell"). Now most of the technical issues should be solved.
[+] [-] MaxGabriel|11 years ago|reply
Hackage is the core package server, comparable to RubyGems.
The Stackage (http://www.stackage.org/) project functions like a CI system for Hackage. Stackage builds and tests the group of packages that have opted in to it, ensuring that the latest versions all work together (when there's an incompatibility between packages, the authors of the packages are pinged to resolve the issue [1]).
When a build of all the packages succeeds, Stackage generates a "snapshot", a list of all the package versions used for that build (sort of like a Gemfile.lock/Podfile.lock, for the whole ecosystem). Developers can have Cabal (Haskell build tool) use the package versions from that list when installing new packages. This ensures that when you install a new package that it's compatible with the other packages you're currently using.
The issue with those snapshots (generated nightly) is that you'll want to get updates for your packages, but the snapshot generated N days from now might have packages that have made breaking API changes, making them incompatible with your application.
LTS Haskell attempts to fix that. It's based off a specific Stackage snapshot. For the duration of the LTS (currently 3 months), the major versions from that snapshot are locked down, but patches/bugfixes will continue to be released. This allows you to get bugfixes for your application while still getting the advantages of Stackage.
[1] As an example, when the language-ecmascript 0.17 package was released, the authors of the 2 packages that depended on language-ecmascript < 0.17 were pinged to update their packages: https://github.com/fpco/stackage/issues/390
[+] [-] mrottenkolber|11 years ago|reply
I works pretty well in the CL world, I think this approach (releases) will become standard for package management in Ecosystem-package-managers (as it has been in the OS world).
[+] [-] cschneid|11 years ago|reply
Hackage - live packages get uploaded and released fast
Stackage - a rolling tested release. It promises that all packages will compile together. (There are a few flavors of this).
and now LTS Haskell. A snapshot of Stackage that doesn't roll very quickly (every 3 months). It won't do upgrades to packages at all, except for bug fix & patch releases. So your own application code can pull down the LTS today, and again tomorrow, and be relatively sure that everything will work the same.
[+] [-] SideburnsOfDoom|11 years ago|reply
This page says "Run weekly point releases"
Is this a bizarrely very-rapid software ecosystem where a week is considered "long term". Or am I missing something?
[+] [-] MaxGabriel|11 years ago|reply
[+] [-] ryanmk|11 years ago|reply
[+] [-] tel|11 years ago|reply
1. Due to static typing package combination errors are detected at compile time not runtime. This means that potential mismatches in package versions are detected and punished very early and very severely. This is why Cabal compares so disfavorably to NPM. It's not that NPM is more advanced, it's that Cabal tries harder to ensure that package mismatches don't survive build.
2. There are differences in opinion on the right place to put burden of package matching—should the maintainers exhaustively test things and maintain accurate and complete information at all times? Or should people just tell them quickly when things break. Unfortunately, these two methods of handling versioning don't live together nicely and they wreck havoc for the solver.
3. Haskell as a language strongly promotes chunking off nice, trustworthy abstractions and squirreling them away into their own package. This means that there are a lot of packages all versioning against one another and the package matching problem is quite large.
So, atop this a few "curated sets" have been built which push the package managing troubles to someone else---namely a build farm where, arguably, it ought to be. These sacrifice bleeding edge availability for a bit less personal burden finding compatible package sets. The two I use are called Stackage and Nixpkgs.
Stackage is in particular supported by the company FPComplete and FPComplete sells Haskell solutions to industry. They are therefore well-interested in providing a support solution for stable sets of packages from Stackage. This may even just be a formalization of what they already do since they probably cannot justify code breakages to customers as "well, the state of the art of libraries keeps changing".
As far as I can tell these LTS package sets are stable points in the master package set which will receive bugfixes and unquestionably unbreaking feature updates alone. In terms of the PVP, they can receive minor version bumps but are protected against major ones. Stackage is a rather massive set of packages, so this is done in a pretty conservative manner and it seems reasonably experimental at the moment.
https://www.fpcomplete.com/blog/2014/12/backporting-bug-fixe...
In particular, it'll come down to the willingness of library maintainers to backport bugfixes to prior major versions of their libraries. Good library maintainers have support windows they care about already, but not everyone has the resources to pull that off. LTS will feel this differential effect.
Anyway, hopefully that's a good, reasonably correct overview. Corrections welcome.
[+] [-] exDM69|11 years ago|reply
Haskell has been notorious for moving (too?) fast while not maintaining decent backwards/forwards compatibility, a problem made worse by some tooling issues ("cabal hell"). Now most of the technical issues should be solved.
[+] [-] wwkeyboard|11 years ago|reply
[+] [-] freyrs3|11 years ago|reply
[+] [-] cm3|11 years ago|reply
[+] [-] ehamberg|11 years ago|reply
[+] [-] namelezz|11 years ago|reply
[+] [-] cbd1984|11 years ago|reply