@@ -6,6 +6,8 @@ The idea behind Stackage is that, if all packages work with the newest versions
6* All packages are compatible with the newest versions of all dependencies (You can find restrictive upper bounds by visiting http://packdeps.haskellers.com/feed?needle=PACKAGENAME).
6* All packages are compatible with the newest versions of all dependencies (You can find restrictive upper bounds by visiting http://packdeps.haskellers.com/feed?needle=PACKAGENAME).
7* All packages in a snapshot are compatible with the versions of libraries that ship with the GHC used in the snapshot ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
7* All packages in a snapshot are compatible with the versions of libraries that ship with the GHC used in the snapshot ([more information on lenient lower bounds](https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds)).
9+Packages in Stackage are not patched: all package changes occur upstream in Hackage.
9## Adding a package
11## Adding a package
11Anyone can add any package to Stackage but you may only add packages under your own name. It's highly encouraged that the actual package maintainer is also the Stackage maintainer, if that is not the case you should drop the package maintainer a note first.
13Anyone can add any package to Stackage but you may only add packages under your own name. It's highly encouraged that the actual package maintainer is also the Stackage maintainer, if that is not the case you should drop the package maintainer a note first.
@@ -44,29 +46,43 @@ recommend waiting an hour before opening the PR. You can verify this
44by making sure the latest version is listed at
46by making sure the latest version is listed at
45https://github.com/commercialhaskell/all-cabal-metadata/tree/master/packages/.
47https://github.com/commercialhaskell/all-cabal-metadata/tree/master/packages/.
47−## Uploading a new package
49+## Uploading a new package version
49−When a new version of a package is uploaded to Hackage, we automatically try to include it in Stackage (unless the new version is considered experimental). That can result in a number of possible failures. If there is a failure we temporarily introduce an upper bound, and raise GitHub issue tickets to resolve the issue.
51+When a new version of a package in Stackage is uploaded to Hackage, we automatically try to include it in Stackage (unless the new version is considered experimental). That can result in a number of possible failures. If there is a failure we temporarily introduce an upper bound, and open a GitHub issue ticket to resolve the issue.
51−If the new version doesn't compile then the package author should quickly (within 1 week) upload a fixed version.
53+If the new version doesn't compile then the package author should upload a fixed version.
53If a package's test suite is failing, the first job is to investigate why. If this is due to a bad interaction with versions of other packages in Stackage, then it is the responsibility of the maintainer to fix the test suite. In some situations, it is acceptable to not run the test suite.
55If a package's test suite is failing, the first job is to investigate why. If this is due to a bad interaction with versions of other packages in Stackage, then it is the responsibility of the maintainer to fix the test suite. In some situations, it is acceptable to not run the test suite.
56## Following dependency upgrades
58## Following dependency upgrades
58−If a new version of a dependency is released, and that stops your package compiling/passing the tests, then it is your responsibility to modify your package. It is highly recommended that all package maintainers follow the dependencies of their packages on [Packdeps](http://packdeps.haskellers.com/), typically using the RSS feeds.
60+If a new version of a dependency is released, and that stops your package compiling/passing the tests, then it is your responsibility to modify your package. It is recommended that all package maintainers follow the dependencies of their packages on [Packdeps](http://packdeps.haskellers.com/), typically using the RSS feeds.
60−**If restrictive version bounds are the only problem** then you must quickly (within 1 week) upload a new version with relaxed version bounds. Note that unlike the PVP, Stackage does not require upper bounds.
62+If a package is not modified in a timely manner, it may be temporarily
63+removed from Stackage by the curator team, at which point it is your
64+responsibility to add it back in via a new pull request. We typically
65+use fairly long windows on this, but at a minimum:
62−**If the new dependency causes breaking changes** then all package authors should quickly assess the likely impact on their package (within 1 week) and then produce a new compatible version. The expected timeline for new versions varies between 1 week and 1 month, depending on the significance of the change, and thus the work required to produce those new versions.
67+* If restrictive version bounds are the only problem, we will give at
68+ least a week to respond.
69+* If there are real breaking changes, the curator team will retain
70+ more discretion on how long a window to give before dropping
71+ packages. Historically, this has usually waited until the cutting of
72+ a new Long Term Support (LTS) major version.
74+**NOTE** Previously, this maintainer agreement put a time limit on
75+maintainers, requiring a certain level of responsiveness for
76+modifications to be made. We have explicitly removed that: anyone is
77+free to add a package to Stackage regardless of responsiveness
78+guarantees. However, as stated above, we may elect to temporarily
79+remove a package if it is not updated in a timely manner.
65## Failing to meet the time limits
81## Failing to meet the time limits
67Maintainers are humans, humans get sick/have babies/go on holiday. If you have regular problems meeting the limits, find a co-maintainer. If you have a one-off problem, respond to the GitHub tickets saying so, and some kind soul might pick up the slack.
83Maintainers are humans, humans get sick/have babies/go on holiday. If you have regular problems meeting the limits, find a co-maintainer. If you have a one-off problem, respond to the GitHub tickets saying so, and some kind soul might pick up the slack.
69−The time limits are intended to stop people being inconvenienced because of problems in other packages. Where such inconvenience happens, we will drop the offending packages from Stackage. While upper bounds are sometimes a temporary solution, they are against the ethos of Stackage, so will not be kept for long.
85+The soft time limits are intended to prevent people being inconvenienced because of problems in other packages. Where such inconvenience happens, we will drop the offending packages from Stackage. While upper bounds are sometimes a temporary solution, they are against the ethos of Stackage, so will not be kept for longer periods.
71## Upgrading to a new GHC version
87## Upgrading to a new GHC version