
Announcing LTS Haskell 1.0 - lelf
https://www.fpcomplete.com/blog/2015/01/announcing-lts-haskell-1-0
======
MaxGabriel
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](https://news.ycombinator.com/item?id=8834823))

Hackage is the core package server, comparable to RubyGems.

The Stackage ([http://www.stackage.org/](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](https://github.com/fpco/stackage/issues/390)

------
mrottenkolber
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).

~~~
cschneid
Sorta yes. In order of wild-west to stable, it's:

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
"LTS" usually stands for "Long Term Support".

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
The weekly point releases are bugfixes for that LTS (so 1.1 is just bugfixes
for 1.0).

~~~
creichert
In addition to this, the release duration is somewhat experimental.

 __ _Why such short support windows? The strawmen of three months between
releases and a one month grace period are ridiculously short support windows.
The reason I propose them is because- like I mentioned in the design goals- we
want the smallest delta from how people work today. Right now, there is no
concept of stable versions, and we 're trying to introduce it. Starting off
with a more standard support window of something like two years would be a
radical shift in how library users and authors operate today. Three months is
very short, but it's long enough for us to test the process. As time goes on,
we should have serious community discussions on how long a support window we
should have. (I, for one, am fully in favor of extending it well beyond three
months.)_ __

------
ryanmk
The website doesn't say what LTS haskell is. A curated set of packages? Of
what?

~~~
exDM69
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.

~~~
tel
As far as I'm aware this has nothing to do with the Haskell Platform and is,
in fact, more or less a competitor.

~~~
dons
It does seem to be a competitor. They could use the same infra to do the HP
versioning and builds. Some NIH going on? The key here seems to be the level
of automation, which is great to see.

~~~
tel
Unfortunately, I think it's a bit of a branding thing, too. To most people's
eyes the HP is something of a failure since it's so slow to release—never mind
the stabilizing effect it has had on all constituent projects. Stackage thus
grabbed some market- and mind-share by promising a closer-to-bleeding-edge
update path at the cost of lesser stability. From this position they're
peeling back a little bit, trading off newness for a bit more stability, in
what appears to be the easiest-to-maintain fashion.

So from that, it's sort of culturally incompatible with HP, unfortunately.
It'd be very nice if some crosscutting could be had once-and-if LTS stabilizes
as a product.

~~~
snoyberg
Actually, the ideas for LTS Haskell came out of conversations I had with
Duncan and Mark at ICFP. The original idea was to create a GPS Haskell that
would encompass a "best of both worlds." LTS Haskell is a first step towards
that, and I'm hoping that Haskell Platform and Hackage ultimately fold this
stuff back in.

I went into more detail on this history in the previous blog post:
[https://www.fpcomplete.com/blog/2014/12/backporting-bug-
fixe...](https://www.fpcomplete.com/blog/2014/12/backporting-bug-fixes)

~~~
dons
Sounds good. I had assumed you were heading in this direction. The approach
was something Duncan and I wanted to try in 2007/2008 but we didn't have
resources at the time. Now the infrastructure is there, automatically
identifying stable sets, tagging and releasing them is a good step. If you can
get to the point of computing the next HP set in the same fashion, that will
be a big win for stability.

------
wwkeyboard
So what happened to the "avoid success at all costs" motto?

~~~
freyrs3
It has two different parsings:

    
    
        avoid (success at all costs)
        (avoid success) at all costs
    

The first is more apt description of Haskell's design, the later is more of a
joke.

~~~
dguaraglia
One could say that the second parsing is... too eager? :)

------
namelezz
What does LTS stand for? My dirty guess is Love ThreeSome.

~~~
cbd1984
Long Term Support

