4[](https://travis-ci.org/fpco/stackage)
6"Stable Hackage": creating a vetted set of packages from Hackage.
7This repository is for package authors and maintainers to get their packages into Stackage.
8If you simply want to use Stackage as an end user, please follow the instructions on [https://www.stackage.org/](https://www.stackage.org).
10We strongly recommend using the Haskell tool stack for doing builds, which
11includes built-in Stackage support: [stack](https://github.com/commercialhaskell/stack) [](https://travis-ci.org/commercialhaskell/stack).
17We welcome all packages, provided:
19* The package author/maintainer agrees to the [maintainers agreement](https://github.com/fpco/stackage/blob/master/MAINTAINERS.md).
20* The package is buildable and testable from Hackage. We recommend [the Stack Travis script](https://docs.haskellstack.org/en/stable/travis_ci/), which ensures a package is not accidentally incomplete.
21* The package is compatible with the newest versions of all dependencies (You can find restrictive upper bounds by visiting http://packdeps.haskellers.com/feed?needle=PACKAGENAME).
22* The package is compatible with the versions of libraries that ship with GHC ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
24Full details on how to add and test a package can be found in the [maintainers agreement](https://github.com/fpco/stackage/blob/master/MAINTAINERS.md#adding-a-package).
26__NOTE__: There is an approximate 30 minute delay between a package uploading
27to Hackage and being available to the Travis build script to check upper
28bounds. If a pull request is marked as failed due to using an older version,
29please close and reopen the PR to retrigger a Travis build.
34The Stackage project consists of multiple repositories. This repository
35contains the metadata on packages to be included in future builds and some
36project information. In addition, we have the following repositories:
38* [stackage-server](https://github.com/fpco/stackage-server) [](https://travis-ci.org/fpco/stackage-server)
39* [stackage-curator](https://github.com/fpco/stackage-curator) [](https://travis-ci.org/fpco/stackage-curator)
40* [lts-haskell](https://github.com/fpco/lts-haskell)
41* [stackage-nightly](https://github.com/fpco/stackage-nightly)
43We also support some add-on tools to cabal-install to make its usage with
44Stackage both easier and more secure:
46* [stackage-cli](https://github.com/fpco/stackage-cli) [](https://travis-ci.org/fpco/stackage-cli)
47* [stackage-update](https://github.com/fpco/stackage-update) [](https://travis-ci.org/fpco/stackage-update)
48* [stackage-upload](https://github.com/fpco/stackage-upload) [](https://travis-ci.org/fpco/stackage-upload)
49* [stackage-install](https://github.com/fpco/stackage-install) [](https://travis-ci.org/fpco/stackage-install)
50* [stackage-build-plan](https://github.com/fpco/stackage-build-plan) [](https://travis-ci.org/fpco/stackage-build-plan)
52Curious how it all fits together? See the [Stackage data
53flow](https://github.com/fpco/stackage/blob/master/DATA-FLOW.md).
59Generally only the stackage build server run by the stackage curator
60team and people interested in incorporating stackage snapshots into an
61OS distribution need to build the entire package set. If you're
62interested in trying this yourself, please check out
63[the curator guide](https://github.com/fpco/stackage/blob/master/CURATORS.md),
64though be aware that this is not a recommended practice and there
65likely will be problems you will need to debug yourself.
69The following describes at a high level the series of steps for processing
731. Get list of core packages
742. Get build constraints from list of maintained packages
753. Load up package index
764. Calculate build plan using newest versions of packages
775. Write out a YAML file with complete build plan
786. Verify that the build plan can be compiled
831. Load up most recent build plan
842. Convert build plan into constraints for next build
853. Continue from step (3) above
87Frequently Asked Questions
88--------------------------
90__Why does Stackage have an older version of a package than Hackage?__
92There are a number of answers to this question:
94* Simplest reason: how old of a Stackage snapshot are you using? Once a
95 snapshot is created, it's frozen for all time. So if you use
96 nightly-2016-01-01, by the time you get to 2018, it will be pretty dated.
97* If you're using an LTS snapshot: we lock down major versions when
98 first creating an LTS run, so subsequent minor versions will not get
99 new versions necessary. For example, if LTS 6.0 has `foo` version
100 1.2.3, and the author immediately thereafter releases a version
101 1.3.0 and never releases another 1.2.\* version, you'll never get
102 another update in the LTS 6 line
103* Sometimes we have upper bounds in place because other packages have
104 problems with newer versions of dependencies. Open up the
105 [build-constraints file](https://github.com/fpco/stackage/blob/master/build-constraints.yaml)
106 and search for "Stackage upper bounds"
107* Wired-in packages - those that ship with GHC and cannot be upgraded,
108 and packages depending on them - are fixed to GHC versions. Common
109 examples of this are containers and transformers. There's a lot more
110 information on this in
111 [an FP Complete blog post](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)
113__How long do you maintain an LTS build?__
115We only guarantee that we will maintain a single LTS major version at
116a time, and that it will be maintained for at least three months. This
118[originally proposed support window](https://www.fpcomplete.com/blog/2014/12/backporting-bug-fixes),
119and hasn't changed since then.
121That said, we do maintain the capability to keep multiple LTS runs
122operational in parallel, and with LTS 6 and 7 in fact did so. We
123aren't changing our guarantees yet on longevity of a release, but are
124trying to push out the bounds a bit farther.
126__What time are Stackage snapshots published?__
128Stackage Nightly and LTS are not released at a fixed time of day, they get pushed to stackage.org (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.
keysesc to close
- j k
- move down, up
- enter
- open
- esc
- back, or up a level
- 1 2 3 4
- readme, files, commits, refs
- /
- filter
- y
- copy the clone command
- c
- compare the chosen commit with another (or shift-click both)
- ?
- show or hide this list