-
Notifications
You must be signed in to change notification settings - Fork 19
Home
versioneer
will automatically take care of most of the version numbers, but unfortunately does not work with the documentation configuration. (This step could probably be avoided by moving away from versioneer
, e.g. to setuptools_scm
.)
- Create a new branch
- Update the
release
version number indoc/conf.py
. Use the same semantic version number as used by the tag below. - Upload your branch, create a pull request, and have it merged.
git tag v1.0.0
git push --tags
Use semantic versioning as major.minor.patch
, see https://semver.org. Short summary:
- For releases which just patch existing functionality (fully backward-compatible), increase the
patch
number. - For minor releases, which introduce new functionality, but remain fully backward-compatible, increase the
minor
number, and reset thepatch
number to 0. - For major releases, which may break the public API, increase the
major
number, and reset the remaining numbers to 0. - For prereleases, append an identifier to the version number, such as
1.0.0b2
for the second beta, or1.0.0rc1
for the first release candidate.
Note: The major / minor / patch version numbers are not decimal. If version 1.0.9 is patched, the next version will be 1.0.10, not 1.1.0 (except if it qualifies as a minor release, of course)!
python setup.py sdist bdist_wheel
twine check dist/*
twine upload --repository-url https://test.pypi.org/legacy/ dist/*
Make sure that upload succeeds, that page https://test.pypi.org/project/physical-validation/[version]/ looks good, and that you can install it using pip install -i https://test.pypi.org/simple/ physical-validation==[version]
.
twine upload dist/*
Note that there are two separate accounts for PyPI and PyPI test! Check again that the page on PyPI looks good, and that pip install
works.
Head over to https://github.com/conda-forge/physical_validation-feedstock and check for a PR posted by a bot. Review the PR and merge it.
Following the checklist above will automatically create a new stable
documentation version thanks to the semantic versioning tag.
latest
will always point to current master
HEAD
.
https://docs.readthedocs.io/en/stable/versions.html
The Zenodo integration is only picking up GitHub Releases, not Git tags, so we also need to create a GitHub Release.
- Open https://github.com/shirtsgroup/physical_validation/releases.
- Click "Draft a new release".
- In the "Choose a tag" dropdown menu, pick the tag you just uploaded.
- Click on "Auto-generate release notes". This will populate the title and description of the release.
- Leave the title (which should simply be the tag name, i.e. the version number) as is.
- Reformulate the description to highlight the important changes. Leave out commits like "bumped the version number".
- Optionally, acknowledge people that helped.
- Leave the "Full Changelog:" link.
- Publish the release.