@@ -218,18 +218,26 @@ Preparing a release
218218For package maintainers, here is how we release a new version:
219219
220220#. Ensure that the ``CHANGES `` file is up to date with the latest changes.
221- #. Create a tag whose name is the `PEP 440 `_-compliant version number prefixed
222- by ``v ``, making sure to include at least three version number components
223- (e.g. ``v0.6.0 ``).
224- #. Make sure that all tests pass on the tagged version.
225- #. Push the tag to Github.
226- #. Make a fresh clone of the repository, and in the root directory of the new
227- clone, run ``pyproject-build `` (from the `build `_ package). This will create
228- source and wheel packages under ``dist/ ``.
229- #. Upload the source and wheel to PyPI using ``twine upload `` (see `twine `_).
230- #. Using the `new release form on Github `_, prepare notes for the new release
231- following the pattern of previous releases. The "Auto-generate release notes"
232- button will be useful in summarizing the changes since the last release.
221+ #. Make sure that all tests pass on the version you want to release.
222+ #. Use the `new release form on Github `_ (or some other equivalent method) to
223+ create a new release, following the pattern of previous releases.
224+
225+ * Each release has to be based on a tag. You can either create the tag first
226+ (e.g. using ``git tag ``) and then make a release from that tag, or you can
227+ have Github create the tag as part of the process of making a release;
228+ either way works.
229+ * The tag name **must ** be the `PEP 440 `_-compliant version number prefixed
230+ by ``v ``, making sure to include at least three version number components
231+ (e.g. ``v0.6.0 ``).
232+ * The "Auto-generate release notes" button will be useful in summarizing
233+ the changes since the last release.
234+
235+ #. Using either the `release workflows page `_ or the link in the email you
236+ received about a "Deployment review", go to the workflow run created for
237+ the new release and click "Review deployments", then either approve or reject
238+ the two deployments, one to Test PyPI and one to real PyPI. (It should not be
239+ necessary to reject a deployment unless something really weird happens.)
240+ Once the deployment is approved, Github will automatically upload the files.
233241
234242----
235243
@@ -254,3 +262,4 @@ For package maintainers, here is how we release a new version:
254262.. _build : https://pypa-build.readthedocs.io/en/latest/
255263.. _twine : https://twine.readthedocs.io/en/stable/
256264.. _new release form on Github : https://github.com/pytest-dev/pytest-localserver/releases/new
265+ .. _release workflows page : https://github.com/pytest-dev/pytest-localserver/actions/workflows/release.yml
0 commit comments