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

LTS guarantees and exceptions

Browse Source
This commit is contained in:
Michael Snoyman 2018-04-15 09:29:50 +03:00
parent ae9f3c921c
commit b2e6bce44b
No known key found for this signature in database
GPG Key ID: A048E8C057E86876
1 changed files with 40 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
MAINTAINERS.md
View File

@ -180,3 +180,43 @@ release (e.g., if `lts-8.9` is out, you would want your package to appear in
but it may take some time. but it may take some time.
* We gradually stop maintainng old LTS major versions, so your * We gradually stop maintainng old LTS major versions, so your
request may take longer or be declined if it's for an old LTS. request may take longer or be declined if it's for an old LTS.
## LTS package guarantees and exceptions
In general, we try to stick to some rules when it comes to the
packages included in LTS minor bumps. In particular:
* If a package exists in LTS-X.Y, it should also exist in LTS-X.(Y+1)
* We should not include a major version bump of a package between
LTS-X.Y and LTS-X.(Y+1)
However, there are some cases where exceptions may be made, based
purely on Stackage Curator discretion. The most common examples are:
* If a package does not follow the PVP in its version number policy,
applying the standard version bump rules would not necessarily
makes sense. As an example, suppose package `foo` decides to
follow SemVer instead of the PVP. By our standard rules of version
bumps, a change from `foo-1.2.0` to `foo-1.3.0` would be
considered a major version bump, and disallowed in an LTS minor
version bump. However, if a package is following SemVer, this
would not be a breaking change, and curators may elect to include
it.
* If a package has overly restrictive version bounds on a
dependency, in particular constraining a minor version
unnecessarily, we may drop that package instead of artificially
holding back the dependency. As an example: suppose `LTS-20.1`
includes `foo-1.2.0` and `bar-1`. `bar-1` has a dependency `foo >=
1.2.0 && < 1.2.1`, which is overly constrained on the minor
version number according to the PVP. Then `foo-1.2.1` is
released. The Stackage Curator team would have two choices:
* Reject `foo-1.2.1` from `LTS-20.2`, since that is what `bar-1`
requires.
* Drop `bar-1` from `LTS-20.2`, and allow `foo-1.2.1`.
Decisions will need to be taken on a case-by-case basis, and may
depend on such issues as whether an important bugfix or security
update in included. The curator team may also try to notify the
author of `bar` to try and get a patched version released.