New production releases should be created every time the main
branch is updated.
For version numbers, we use A.B.C
, where
C
is increased for bug fixes,B
is increased for new features and minor API breaking changes,A
is increased for major API breaking changes,
as suggested by the Python packaging guide.
After new commits have been added via pull requests to the develop
branch, changes can be merged to main
and a new version of pyABC can be released.
- create a pull request from
develop
tomain
, - check that all code changes are covered by tests and all tests pass,
- check that the documentation is up-to-date,
- adapt the version number in
pyabc/version.py
(see above), - update the release notes in
CHANGELOG.rst
, - request a code review,
- merge into the origin
main
branch.
To be able to actually perform the merge, sufficient rights may be required. Also, at least one review is required.
After merging into main
, create a new release on GitHub. This can be done either directly on the project GitHub website, or via the CLI as described in Git Basics - Tagging. In the release form,
- specify a tag with the new version as specified in
pyabc/version.py
, - include the latest additions to
CHANGELOG.rst
in the release description.
The upload to the python package index PyPI has been automatized via GitHub Actions and is triggered whenever a new release tag is published.
Should it be necessary to manually upload a new version to PyPI, proceed as follows: First, a so called "wheel" is created via:
python setup.py bdist_wheel
A wheel is essentially a zip archive which contains the source code and the binaries (if any).
This archive is uploaded using twine:
twine upload dist/pyabc-x.y.z-py3-non-any.wheel
replacing x.y.z by the respective version number.
For a more in-depth discussion see also the section on distributing packages of the Python packaging guide.