@@ -30,7 +30,7 @@ so commit messages like "update build-constraints.yaml" are not helpful).
3030
3131When 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.
3232
33−If the new version doesn't compile then the package author should quickly (within 3 days) upload a fixed version.
33+If the new version doesn't compile then the package author should quickly (within 1 week) upload a fixed version.
3434
3535If 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.
3636
@@ -39,9 +39,9 @@ If a package's test suite is failing, the first job is to investigate why. If th
3939
4040If 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.
4141
42−**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.
42+**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.
4343
44−**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.
44+**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.
4545
4646
4747## Failing to meet the time limits