on master help sign in
Merge pull request #3526 from fpco/lts-guarantees-exceptions
273b449Michael Snoyman
MAINTAINERS.md+40
@@ -180,3 +180,43 @@ release (e.g., if `lts-8.9` is out, you would want your package to appear in
180 but it may take some time.
180 but it may take some time.
181* We gradually stop maintainng old LTS major versions, so your
181* We gradually stop maintainng old LTS major versions, so your
182 request may take longer or be declined if it's for an old LTS.
182 request may take longer or be declined if it's for an old LTS.
183+
184+## LTS package guarantees and exceptions
185+
186+In general, we try to stick to some rules when it comes to the
187+packages included in LTS minor bumps. In particular:
188+
189+* If a package exists in LTS-X.Y, it should also exist in LTS-X.(Y+1)
190+* We should not include a major version bump of a package between
191+ LTS-X.Y and LTS-X.(Y+1)
192+
193+However, there are some cases where exceptions may be made, based
194+purely on Stackage Curator discretion. The most common examples are:
195+
196+* If a package does not follow the PVP in its version number policy,
197+ applying the standard version bump rules would not necessarily
198+ makes sense. As an example, suppose package `foo` decides to
199+ follow SemVer instead of the PVP. By our standard rules of version
200+ bumps, a change from `foo-1.2.0` to `foo-1.3.0` would be
201+ considered a major version bump, and disallowed in an LTS minor
202+ version bump. However, if a package is following SemVer, this
203+ would not be a breaking change, and curators may elect to include
204+ it.
205+
206+* If a package has overly restrictive version bounds on a
207+ dependency, in particular constraining a minor version
208+ unnecessarily, we may drop that package instead of artificially
209+ holding back the dependency. As an example: suppose `LTS-20.1`
210+ includes `foo-1.2.0` and `bar-1`. `bar-1` has a dependency `foo >=
211+ 1.2.0 && < 1.2.1`, which is overly constrained on the minor
212+ version number according to the PVP. Then `foo-1.2.1` is
213+ released. The Stackage Curator team would have two choices:
214+
215+ * Reject `foo-1.2.1` from `LTS-20.2`, since that is what `bar-1`
216+ requires.
217+ * Drop `bar-1` from `LTS-20.2`, and allow `foo-1.2.1`.
218+
219+ Decisions will need to be taken on a case-by-case basis, and may
220+ depend on such issues as whether an important bugfix or security
221+ update in included. The curator team may also try to notify the
222+ author of `bar` to try and get a patched version released.