haskell/stackage
1
0
Fork 0
mirror of https://github.com/commercialhaskell/stackage.git synced 2026-01-12 07:18:31 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Make all maintainer changes take 1 week at minimum

Browse Source
This commit is contained in:
Neil Mitchell 2015-12-07 11:46:14 +00:00
parent 5316860deb
commit 267aee3d43
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
MAINTAINERS.md
View File

@ -30,7 +30,7 @@ so commit messages like "update build-constraints.yaml" are not helpful).
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.
If the new version doesn't compile then the package author should quickly (within 3 days) upload a fixed version.
If the new version doesn't compile then the package author should quickly (within 1 week) upload a fixed version.
If 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.
@ -39,9 +39,9 @@ If a package's test suite is failing, the first job is to investigate why. If th
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.
**If restrictive version bounds are the only problem** then you must quickly (within 3 days) upload a new version with relaxed version bounds. Note that unlike the PVP, Stackage does not require upper bounds.
**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.
**If the new dependency causes breaking changes** then all package authors should quickly assess the likely impact on their package (within 3 days) 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.
**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.
## Failing to meet the time limits