haskell/stackage
1
0
Fork 0
mirror of https://github.com/commercialhaskell/stackage.git synced 2026-01-29 07:30:25 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Add Frequently Asked Questions

Browse Source
This commit is contained in:
Michael Snoyman 2017-01-28 18:52:43 +02:00
parent fb7e7fa430
commit a18238ad1c
1 changed files with 39 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
README.md
View File

@ -84,3 +84,42 @@ The following describes at a high level the series of steps for processing
1. Load up most recent build plan 1. Load up most recent build plan
2. Convert build plan into constraints for next build 2. Convert build plan into constraints for next build
3. Continue from step (3) above 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](https://github.com/fpco/stackage/blob/master/build-constraints.yaml)
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](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)
__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](https://www.fpcomplete.com/blog/2014/12/backporting-bug-fixes),
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.