diff options
author | Ralf Gommers <ralf.gommers@gmail.com> | 2015-10-14 23:33:03 +0200 |
---|---|---|
committer | Ralf Gommers <ralf.gommers@gmail.com> | 2015-10-15 00:16:56 +0200 |
commit | 7b438fa90e53abe8b2f0356ec50daed6ab299794 (patch) | |
tree | 82111508209b8dc7b8a2c0c5bb884883aef737a3 /doc/HOWTO_RELEASE.rst.txt | |
parent | 9a62a26ab9689bbcf8a4eeb0076848ca9c44d4ae (diff) | |
download | python-numpy-7b438fa90e53abe8b2f0356ec50daed6ab299794.tar.gz python-numpy-7b438fa90e53abe8b2f0356ec50daed6ab299794.tar.bz2 python-numpy-7b438fa90e53abe8b2f0356ec50daed6ab299794.zip |
TST: raise errors for dev versions and warnings for releases on test runs.
This approach is less error prone than switching from "develop" to "release"
in maintenance branches by hand. See gh-6461 for details.
Diffstat (limited to 'doc/HOWTO_RELEASE.rst.txt')
-rw-r--r-- | doc/HOWTO_RELEASE.rst.txt | 16 |
1 files changed, 0 insertions, 16 deletions
diff --git a/doc/HOWTO_RELEASE.rst.txt b/doc/HOWTO_RELEASE.rst.txt index a88e4db47..5fed523c1 100644 --- a/doc/HOWTO_RELEASE.rst.txt +++ b/doc/HOWTO_RELEASE.rst.txt @@ -196,16 +196,6 @@ After a date is set, create a new maintenance/x.y.z branch, add new empty release notes for the next version in the master branch and update the Trac Milestones. -Handle test warnings --------------------- -The default behavior of the test suite in the master branch is to report errors -for DeprecationWarnings and RuntimeWarnings that are issued. For a released -version this is not desired. Therefore any known warnings should be solved or -explicitly silenced before making the release branch, then when the branch is -made, the default behavior should be switched to not raise errors. This is -done in the constructor of the NoseTester class in numpy/testing/nosetester.py, -by replacing ``raise_warnings="develop"`` with ``raise_warnings="release"``. - Make sure current trunk builds a package correctly -------------------------------------------------- :: @@ -220,12 +210,6 @@ best to read the pavement.py script. .. note:: The following steps are repeated for the beta(s), release candidates(s) and the final release. -Merge doc wiki edits --------------------- -The edits in the documentation wiki suitable for merging should be merged, -ideally just before making the release branch. How to do this is described in -detail in doc/HOWTO_MERGE_WIKI_DOCS.txt. - Check that docs can be built ---------------------------- Do:: |