mirror of
https://github.com/commercialhaskell/stackage.git
synced 2026-01-11 23:08:30 +01:00
Add Frequently Asked Questions
This commit is contained in:
parent
fb7e7fa430
commit
a18238ad1c
39
README.md
39
README.md
@ -84,3 +84,42 @@ The following describes at a high level the series of steps for processing
|
||||
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](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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user