New production releases should be created every time the
main branch is
For version numbers, we use
Cis increased for bug fixes,
Bis increased for new features and minor API breaking changes,
Ais increased for major API breaking changes,
as suggested by the Python packaging guide.
Create a new release¶
After new commits have been added via pull requests to the
changes can be merged to
main and a new version of pyPESTO can be released.
Merge into main¶
create a pull request from
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
update the release notes in
request a code review,
merge into the origin
To be able to actually perform the merge, sufficient rights may be required. Also, at least one review is required.
Create a release on GitHub¶
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
Git Basics - Tagging.
In the release form,
specify a tag with the new version as specified in
include the latest additions to
CHANGELOG.rstin the release description.
Upload to PyPI¶
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/pypesto-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.