Public | Automated Build

Last pushed: 6 days ago
Short Description
Short description is empty for this repo.
Full Description


"Stable Hackage": creating a vetted set of packages from Hackage.
This repository is for package authors and maintainers to get their packages into Stackage.
If you simply want to use Stackage as an end user, please follow the instructions on

We strongly recommend using the Haskell tool stack for doing builds, which
includes built-in Stackage support: stack .

Add your package

We welcome all packages, provided:

Full details on how to add and test a package can be found in the maintainers agreement.

NOTE: There is an approximate 30 minute delay between a package uploading
to Hackage and being available to the Travis build script to check upper
bounds. If a pull request is marked as failed due to using an older version,
please close and reopen the PR to retrigger a Travis build.

Other repos

The Stackage project consists of multiple repositories. This repository
contains the metadata on packages to be included in future builds and some
project information. In addition, we have the following repositories:

We also support some add-on tools to cabal-install to make its usage with
Stackage both easier and more secure:

Curious how it all fits together? See the Stackage data

Build the package set

Generally only the stackage build server run by the stackage curator
team and people interested in incorporating stackage snapshots into an
OS distribution need to build the entire package set. If you're
interested in trying this yourself, please check out
the curator guide,
though be aware that this is not a recommended practice and there
likely will be problems you will need to debug yourself.


The following describes at a high level the series of steps for processing


  1. Get list of core packages
  2. Get build constraints from list of maintained packages
  3. Load up package index
  4. Calculate build plan using newest versions of packages
  5. Write out a YAML file with complete build plan
  6. Verify that the build plan can be compiled
  7. Perform the build


  1. Load up most recent build plan
  2. Convert build plan into constraints for next build
  3. Continue from step (3) above

Frequently Asked Questions

Why does Stackage have an older version of a package than Hackage?

There are a number of answers to this question:

  • Simplest reason: how old of a Stackage snapshot are you using? Once a
    snapshot is created, it's frozen for all time. So if you use
    nightly-2016-01-01, by the time you get to 2018, it will be pretty dated.
  • If you're using an LTS snapshot: we lock down major versions when
    first creating an LTS run, so subsequent minor versions will not get
    new versions necessary. For example, if LTS 6.0 has foo version
    1.2.3, and the author immediately thereafter releases a version
    1.3.0 and never releases another 1.2.* version, you'll never get
    another update in the LTS 6 line
  • Sometimes we have upper bounds in place because other packages have
    problems with newer versions of dependencies. Open up the
    build-constraints file
    and search for "Stackage upper bounds"
  • Wired-in packages - those that ship with GHC and cannot be upgraded,
    and packages depending on them - are fixed to GHC versions. Common
    examples of this are containers and transformers. There's a lot more
    information on this in
    an FP Complete blog post

How long do you maintain an LTS build?

We only guarantee that we will maintain a single LTS major version at
a time, and that it will be maintained for at least three months. This
is the
originally proposed support window,
and hasn't changed since then.

That said, we do maintain the capability to keep multiple LTS runs
operational in parallel, and with LTS 6 and 7 in fact did so. We
aren't changing our guarantees yet on longevity of a release, but are
trying to push out the bounds a bit farther.

What time are Stackage snapshots published?

Stackage Nightly and LTS are not released at a fixed time of day, they get pushed to (and the metadata to the stackage-nightly and stackage-lts github repos) when their builds finish on the Stackage build server and the latest built haddocks have been synced over. This time varies greatly depending on build times for package updates, bounds breakage, problems with new packages being added and other build issues, etc. There are days when a release does not happen. LTS releases tend to happen over the weekend or early in the week.

Docker Pull Command
Source Repository