Deploy
New production releases should be created every time the main
branch is
updated.
Versions
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.
Create a new release
After new commits have been added via pull requests to the develop
branch,
changes can be merged to main
and a new version of pyPESTO can be released.
Merge into main
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
fitmulticell/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.
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
in
Git Basics - Tagging.
In the release form,
specify a tag with the new version as specified in
fitmulticell/version.py
,include the latest additions to
CHANGELOG.rst
in the release description.
Upload to PyPI
The upload to the python package index PyPI has been automatized via GitLab CI/CD 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/fitmulticell-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.