From ea0e398eb169a79a4f768dd886abbe74387466ca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?H=C3=A5kon=20Wiik=20=C3=85nes?= Date: Sat, 13 May 2023 20:36:29 +0200 Subject: [PATCH] Add a release guide MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Håkon Wiik Ånes --- RELEASE.rst | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 RELEASE.rst diff --git a/RELEASE.rst b/RELEASE.rst new file mode 100644 index 000000000..461e36642 --- /dev/null +++ b/RELEASE.rst @@ -0,0 +1,60 @@ +How to make a new release of pyxem +================================== + +pyxem versioning tries its best to adhere to `Semantic Versioning +`__. +See the `Python Enhancement Proposal (PEP) 440 `__ +for supported version identifiers. + +Preparation +----------- +- Locally, create release branch from the ``main`` branch. + +- Run tutorial notebooks and examples in the documentation locally and confirm that they + produce the expected results. + From time to time, check the documentation links (``make linkchecker``) and fix any + broken ones. + +- Review the contributor list ``credits`` in ``pyxem/release_info.py`` to ensure all + contributors are included and sorted correctly. + Do the same for the Zenodo contributors file ``.zenodo.json``. + +- Increment the version number in ``pyxem/release_info.py``. + Review and clean up ``CHANGELOG.rst`` as per Keep a Changelog. + +- Make a PR of the release branch to ``main``. + Discuss the changelog with others, and make any changes *directly* to the release + branch. + Merge the branch into ``main``. + +Tag and release +--------------- +- Make a tagged release on GitHub. + The tag target is the ``main`` branch. + If ``version`` is now "0.16.0", the release name is "pyxem 0.16.0". + The tag name is "v0.16.0". + The release body should contain a description of what has changed and a link to the + changelog. + +- Monitor the publish workflow to ensure the release is successfully uploaded to PyPI. + If the upload fails, the upload workflow can be re-run. + +Post-release action +------------------- +- Monitor the `documentation build `__ + to ensure that the new stable documentation is successfully built from the release. + +- Ensure that `Zenodo `__ displays the new + release. + +- Make a new PR to ``main``, update ``version`` in ``pyxem/release_info.py`` and make + any updates to this guide if necessary. + +- Tidy up GitHub issues and close the corresponding milestone. + +- A PR to the conda-forge feedstock will be created by the conda-forge bot. + Follow the relevant instructions from the conda-forge documentation on updating + packages, as well as the instructions in the PR. + Merge after checks pass. + Monitor the Azure pipeline CI to ensure the release is successfully published to + conda-forge.