@@ -218,18 +218,26 @@ Preparing a release
218
218
For package maintainers, here is how we release a new version:
219
219
220
220
#. 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.
233
241
234
242
----
235
243
@@ -254,3 +262,4 @@ For package maintainers, here is how we release a new version:
254
262
.. _build : https://pypa-build.readthedocs.io/en/latest/
255
263
.. _twine : https://twine.readthedocs.io/en/stable/
256
264
.. _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