Release process

Feature development takes places on the “master” branch. Periodically, a release is created by increasing the version number and tagging the relevant commit with the new version number.

  • Check that the release passes all of the tests:

    nox

  • Update the version number according to the versioning scheme.

    • Update the version number in doc/conf.py. The full version must always be updated, the short (X.Y) version does not need to be updated if the version number is being increased from X.Y.Z to X.Y.Z+1.

    • Update the version number in pyproject.toml.

  • Check whether the copyright year(s) need to be updated in:

    • LICENSE

    • doc/conf.py

  • Describe the changes at the top of NEWS.rst under a heading of the form X.Y.Z (YYYY-MM-DD), which identifies the new version number and the date on which this version was released.

  • Commit these changes; set the commit message to Release lhs X.Y.Z.

    git add NEWS.rst doc/conf.py pyproject.toml
git commit -m "Release lhs X.Y.Z"

  • Tag this commit X.Y.Z.

    git tag -a X.Y.Z -m "lhs X.Y.Z"

  • Push this commit and the new tag upstream.

    git push --follow-tags

Publishing to PyPI

These instructions are based on the Packaging Python Projects tutorial.

Ensure that build and twine are installed:

pip install build twine

Ensure that all uncommitted changes are stashed, or they will be packaged!

git stash

Build the wheel ./dist/lhs-X.Y.Z-py3-none-any.whl:

python3 -m build

Upload this wheel to the PyPI test server, so that any problems can be identified and fixed:

python3 -m twine upload -r testpypi dist/lhs-X.Y.Z-py3-none-any.whl

Then upload this wheel to PyPI:

python3 -m twine upload dist/lhs-X.Y.Z-py2.py3-none-any.whl