37b9dbdbf4
Following recent discussions, this changes the development process as follows: 1. The deploy is now manually triggered after the release PR is approved. 2. The deploy workflow tags the repository only after the package has been published to PyPI. 3. Use PyPI trusted publishers instead of API tokens. Co-authored-by: Ran Benita <ran@unusedvar.com>
40 lines
1.1 KiB
ReStructuredText
40 lines
1.1 KiB
ReStructuredText
======================
|
|
Releasing pytest-xdist
|
|
======================
|
|
|
|
This document describes the steps to make a new ``pytest-xdist`` release.
|
|
|
|
Version
|
|
-------
|
|
|
|
``master`` should always be green and a potential release candidate. ``pytest-xdist`` follows
|
|
semantic versioning, so given that the current version is ``X.Y.Z``, to find the next version number
|
|
one needs to look at the ``changelog`` folder:
|
|
|
|
- If there is any file named ``*.feature``, then we must make a new **minor** release: next
|
|
release will be ``X.Y+1.0``.
|
|
|
|
- Otherwise it is just a **bug fix** release: ``X.Y.Z+1``.
|
|
|
|
|
|
Steps
|
|
-----
|
|
|
|
To publish a new release ``X.Y.Z``, the steps are as follows:
|
|
|
|
#. Create a new branch named ``release-X.Y.Z`` from the latest ``master``.
|
|
|
|
#. Install ``tox`` in a virtualenv::
|
|
|
|
$ pip install tox
|
|
|
|
#. Update the necessary files with::
|
|
|
|
$ tox -e release -- X.Y.Z
|
|
|
|
#. Commit and push the branch to ``upstream`` and open a PR.
|
|
|
|
#. Once the PR is **green** and **approved**, start the ``deploy`` workflow manually from the branch ``release-VERSION``, passing ``VERSION`` as parameter.
|
|
|
|
#. Merge the release PR to ``master``.
|