Notes on release process following v1.2 and v2.0

Here are some small things to fix based on my v1.2 release notes:

• Step 4 (running tests) should be done after Step 7 (changing branch)
• In step 20, we should use the branch name not the version (which are slightly different)
• When updating the astropy website (point 23), if this is a new major release, we should add a new entry in the ‘previous versions’ of the docs
• For releases that come after release candidates, we should make it clear that the title of the changelog section should be replaced, and the RC section headings should not be kept
• Since it’s easy to do, the latest ‘stable’ version of astropy in ci-helpers should be updated, so probably worth mentioning (though this could also be done by the ci-helpers once the release is announced)
• We should mention that announcement emails need to be prepared, and give a list of mailing lists to email - this should include the step of adding the announcement to the astropy web site
• For release candidates, we should mention that a wiki page should be created to collect test results
• The release candidate instructions mention to ignore steps 21 and above, but step 22 (RTD) should be done for RCs
• In step 15, this won’t run the tests with all the optional dependencies installed, so we should probably change that
• We should maybe recommend a set of additional tests to run when branching or making an RC - for example we often get reports from 32-bit linux systems, and issues that come from running tests twice in the same session. We might want to suggest these are done as soon as feature freeze, to have more time to work on those issues.
• We should add a mention in the feature freeze section of the release instructions to note that the “Release final vx.y” issue should get created at the time of feature freeze

EDIT (by bsipocz): Other suggestions based on 2.0 experience. The above list needs revision as we’ve already updated the release docs after the 1.3 release, so I expect most of it is either covered already or outdated (the numbering is definitely outdated). There are also a few new points worth discussing:

• - point 12&13 could be moved to the bottom as there is no development going on on a bugfix branch anyway, so both the version and changelog can be dealt with once everything is ready and we’re just waiting for the conda packages to being built
• - if we keep building the wheels as part of the release, point 25 needs to be done before the wheels as they need to know about the new version tag
• - changelog script doesn’t know about minor releases, be careful with backports after major releases (e.g. 3.0.1 PRs are already been merged, but 3.0 is not yet out, then hold up backporting the 3.0.1 ones until 3.0 is released from the branch)
• - remove mention of suggest_backports.py and update with the current suite of scripts.
• - mention that we now have twine check: which can be used to make sure (amongst other things) that the rst that will be used on PyPI is fine
• - add notes about having the latest Cython version when releasing, just to have a procedure that can be followed. e.g. pip install Cython --upgrade can be a step as suggested in https://github.com/astropy/astropy/issues/3473

[eteq]

Maybe our immediate post-release assignment is to actually finish off this issue…

[pllim]

Also not clear what is “point 12&13 could be moved to the bottom,” so I’ll leave that one alone for now.