The Stackage team is proud to announce the release of LTS Haskell 2. To quote the package page:

LTS Haskell: Version your Ecosystem

LTS (Long Term Support) Haskell is a curated set of packages

which includes non-breaking point releases. It is a companion to

Stackage Nightly: whereas Stackage Nightly releases include

potentially breaking changes with each new release, LTS Haskell

maintains major version stability for a longer period of time.

As usual, to start using LTS Haskell, you typically need to run the command wget https://www.stackage.org/lts/cabal.config in your package directory. More detailed instructions are available on the LTS Haskell 2 page itself.

This release is significant in that it is the first major

version bump we've performed on LTS Haskell. I'm also happy to note

that, despite some earlier concerns, both primitive 0.6 and blaze-builder 0.4

made it in, thanks to last minute patches by Emanuel Borsboom,

Simon Meier, Edward Kmett, and Gregory Collins.

I'm also happy to announce that, in the three months since LTS 1

was released, there has been a significant surge in involvement

from the community. For comparison:

Measurement LTS 1.0 LTS 2.0 Core packages 29 29 Non-core packages 833 1030 Total packages 862 1059 Unique maintainers 67 96

I'm excited to see the community embrace this project so fully, and look forward to the trend continuing.

The road to 3.0

The current plan is to target the LTS 3.0 release some time around

August, depending on when the Hackage ecosystem updates to GHC 7.10

fully. The goal is to make sure the 3.0 is switched over to GHC

7.10.

In addition, Daniel Bergey sent an email which resulted in some questions from me about how we should plan and

communicate around LTS major bumps. To summarize my goals and

ideas:

• We need to make sure package authors understand when a release

  is coming out, and the importance of making their packages

  compatible with upstream dependencies. I believed previously that

  the issue tracker on the Stackage repo was sufficient to indicate

  this to authors, but Daniel's questions and other responses I

  received from package authors tells me that we need some more

  explicit communication. Perhaps there should be an email 1-2 weeks

  in advance of the release warning about restrictive upper

  bounds.

• How strictly should we adhere to a release schedule? I want to

  make sure that LTS Haskell is a reliable release, but perhaps

  providing a release window of 1-2 weeks instead of a hard release

  date will give package authors some necessary flexibility.

• Since Stackage Nightly is essentially the testing ground for

  new LTS major bumps, how aggressive should we be on removing

  packages with restrictive upper bounds? I've been pretty lenient

  until now. However, this is a two-edged sword. Allowing upper

  bounds to creep in makes the lives of some authors easier, but

  makes the lives of other authors (the ones updating their packages

  regularly) much more difficult.

I don't want to make any of these decisions myself, as they're

pretty central to how the LTS ecosystem is going to operate. If you

have thoughts on any of these points- or on points I haven't

raised- please bring them up on the Stackage mailing list and/or Reddit.