Announcing: LTS (Long Term Support) Haskell 2

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.

Subscribe to our blog via email

Email subscriptions come from our Atom feed and are handled by Blogtrottr. You will only receive notifications of blog posts, and can unsubscribe any time.