Release ProcessΒΆ
Make sure all tests pass.
Increment version number in
cloudbridge/__init__.py
as per semver rules.Freeze all library dependencies in
setup.py
and commit. The version numbers can be a range with the upper limit being the latest known working version, and the lowest being the last known working version.In general, our strategy is to make provider sdk libraries fixed within relatively known compatibility ranges, so that we reduce the chances of breakage. If someone uses CloudBridge, presumably, they do not use the SDKs directly. For all other libraries, especially, general purpose libraries (e.g.
six
), our strategy is to make compatibility as broad and unrestricted as possible.Add release notes to
CHANGELOG.rst
. Also add last commit hash to changelog. List of commits can be obtained usinggit shortlog <last release hash>..HEAD
Release to PyPi. (make sure you have run pip install wheel twine) First, test release with PyPI staging server as described in: https://hynek.me/articles/sharing-your-labor-of-love-pypi-quick-and-dirty/
Once tested, run:
# remove stale files or wheel might package them
rm -r build dist
python setup.py sdist bdist_wheel
twine upload -r pypi dist/cloudbridge-3.0.0*
Tag release and make a GitHub release.
git tag -a v3.0.0 -m "Release 3.0.0"
git push
git push --tags
Increment version number in
cloudbridge/__init__.py
toversion-dev
to indicate the development cycle, commit, and push the changes.