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.
Do you like this blog post and need help with Next Generation Software Engineering, Platform Engineering or Blockchain & Smart Contracts? Contact us.