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.
* We gradually stop maintainng old LTS major versions, so your
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.