Release ProcessΒΆ

  1. Make sure all tests pass.

  2. Increment version number in cloudbridge/ as per semver rules.

  3. Freeze all library dependencies in 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.

  4. Add release notes to CHANGELOG.rst. Also add last commit hash to changelog. List of commits can be obtained using git shortlog <last release hash>..HEAD

  5. Release to PyPi. (make sure you have run pip install wheel twine) First, test release with PyPI staging server as described in:

    Once tested, run:

# remove stale files or wheel might package them
rm -r build dist
python sdist bdist_wheel
twine upload -r pypi dist/cloudbridge-3.0.0*
  1. Tag release and make a GitHub release.

git tag -a v3.0.0 -m "Release 3.0.0"
git push
git push --tags
  1. Increment version number in cloudbridge/ to version-dev to indicate the development cycle, commit, and push the changes.