4[](https://travis-ci.org/commercialhaskell/stackage)
5[](https://gitter.im/commercialhaskell/stackage?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
7"Stable Hackage": creating a vetted set of packages from Hackage.
8This repository is for package authors and maintainers to get their packages into Stackage.
9If you simply want to use Stackage as an end user, please follow the instructions on [https://www.stackage.org/](https://www.stackage.org).
11We strongly recommend using the Haskell tool stack for doing builds, which
12includes built-in Stackage support: [stack](https://github.com/commercialhaskell/stack) [](https://dev.azure.com/commercialhaskell/stack/_build/latest?definitionId=1?branchName=master).
18We welcome all packages, provided:
20* The package author/maintainer agrees to the [maintainers agreement](https://github.com/commercialhaskell/stackage/blob/master/MAINTAINERS.md).
21* 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.
22* 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).
23* The package is compatible with the versions of libraries that ship with GHC ([more information on lenient lower bounds](https://tech.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
25Full details on how to add and test a package can be found in the [maintainers agreement](https://github.com/commercialhaskell/stackage/blob/master/MAINTAINERS.md#adding-a-package).
27__NOTE__: There is an approximate 30 minute delay between a package uploading
28to Hackage and being available to the Travis build script to check upper
29bounds. If a pull request is marked as failed due to using an older version,
30please close and reopen the PR to retrigger a Travis build.
35The Stackage project consists of multiple repositories. This repository
36contains the metadata on packages to be included in future builds and some
37project information. In addition, we have the following repositories:
39* [stackage-server](https://github.com/fpco/stackage-server) [](https://travis-ci.org/fpco/stackage-server)
40* [stackage-curator](https://github.com/fpco/stackage-curator) [](https://travis-ci.org/fpco/stackage-curator)
41* [lts-haskell](https://github.com/fpco/lts-haskell)
42* [stackage-nightly](https://github.com/fpco/stackage-nightly)
44We also support some add-on tools to cabal-install to make its usage with
45Stackage both easier and more secure:
47* [stackage-cli](https://github.com/fpco/stackage-cli) [](https://travis-ci.org/fpco/stackage-cli)
48* [stackage-update](https://github.com/fpco/stackage-update) [](https://travis-ci.org/fpco/stackage-update)
49* [stackage-upload](https://github.com/fpco/stackage-upload) [](https://travis-ci.org/fpco/stackage-upload)
50* [stackage-install](https://github.com/fpco/stackage-install) [](https://travis-ci.org/fpco/stackage-install)
51* [stackage-build-plan](https://github.com/fpco/stackage-build-plan) [](https://travis-ci.org/fpco/stackage-build-plan)
53Curious how it all fits together? See the [Stackage data
54flow](https://github.com/commercialhaskell/stackage/blob/master/DATA-FLOW.md).
60Generally only the stackage build server run by the stackage curator
61team and people interested in incorporating stackage snapshots into an
62OS distribution need to build the entire package set. If you're
63interested in trying this yourself, please check out
64[the curator guide](https://github.com/commercialhaskell/stackage/blob/master/CURATORS.md),
65though be aware that this is not a recommended practice and there
66likely will be problems you will need to debug yourself.
70The following describes at a high level the series of steps for processing
741. Get list of core packages
752. Get build constraints from list of maintained packages
763. Load up package index
774. Calculate build plan using newest versions of packages
785. Write out a YAML file with complete build plan
796. Verify that the build plan can be compiled
841. Load up most recent build plan
852. Convert build plan into constraints for next build
863. Continue from step (3) above
88Frequently Asked Questions
89--------------------------
91__Why is Stackage LTS still on an older version of GHC?__
93Typically it takes some months from a new major ghc release before
94the Haskell ecosystem supports it fully enough that we can push it
95to a new stable Stackage major version release. The lag for minor ghc releases
96should be less but it still requires extra work and there is usually
97some delay, but this also allows for sufficient community testing before updating.
99eg Currently there is a 8.10.2 issue with linking on Windows.
100Once 8.10.3 is out and we are satisfied it is working well in Nightly
101we will plan to move to release LTS 17 based on ghc-8.10.
103__Why does Stackage have an older version of a package than Hackage?__
105There are a number of answers to this question:
107* Simplest reason: how old of a Stackage snapshot are you using? Once a
108 snapshot is created, it's frozen for all time. So if you use
109 nightly-2016-01-01, by the time you get to 2018, it will be pretty dated.
110* If you're using an LTS snapshot: we lock down major versions when
111 first creating an LTS run, so subsequent minor versions will not get
112 new versions necessary. For example, if LTS 6.0 has `foo` version
113 1.2.3, and the author immediately thereafter releases a version
114 1.3.0 and never releases another 1.2.\* version, you'll never get
115 another update in the LTS 6 line
116* Sometimes we have upper bounds in place because other packages have
117 problems with newer versions of dependencies. Open up the
118 [build-constraints file](https://github.com/commercialhaskell/stackage/blob/master/build-constraints.yaml)
119 and search for "Stackage upper bounds"
120* Wired-in packages - those that ship with GHC and cannot be upgraded,
121 and packages depending on them - are fixed to GHC versions. Common
122 examples of this are containers and transformers. There's a lot more
123 information on this in
124 [an FP Complete blog post](https://tech.fpcomplete.com/blog/2014/05/lenient-lower-bounds)
126__How long do you maintain an LTS build?__
128We only guarantee that we will maintain a single LTS major version at
129a time, and that it will be maintained for at least three months. This
131[originally proposed support window](https://tech.fpcomplete.com/blog/2014/12/backporting-bug-fixes),
132and hasn't changed since then.
134That said, we do maintain the capability to keep multiple LTS runs
135operational in parallel, and with LTS 6 and 7 in fact did so. We
136aren't changing our guarantees yet on longevity of a release, but are
137trying to push out the bounds a bit farther.
139__What time are Stackage snapshots published?__
141Stackage Nightly and LTS are not released at a fixed time of day, they get
142pushed to stackage.org (and the metadata to the stackage-nightly and
143stackage-lts github repos) when their builds finish on the Stackage build
144server and the latest built haddocks have been synced over. This time varies
145greatly depending on build times for package updates, bounds breakage,
146problems with new packages being added and other build issues, etc. There are
147days when a release does not happen. LTS releases tend to happen over the
148weekend or early in the week.
150__Where to get help regarding uploading packages?__
152Please ask on [Gitter](https://gitter.im/commercialhaskell/stackage) or open
153an issue or comment on the PR which uploads the package.
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