release_process.rst 1.6 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546
  1. Release Process
  2. ~~~~~~~~~~~~~~~
  3. 1. Make sure `all tests pass <https://travis-ci.org/CloudVE/cloudbridge>`_.
  4. 2. Increment version number in ``cloudbridge/__init__.py`` as per
  5. `semver rules <https://semver.org/>`_.
  6. 3. Freeze all library dependencies in ``setup.py`` and commit.
  7. The version numbers can be a range with the upper limit being the latest
  8. known working version, and the lowest being the last known working version.
  9. In general, our strategy is to make provider sdk libraries fixed within
  10. relatively known compatibility ranges, so that we reduce the chances of
  11. breakage. If someone uses CloudBridge, presumably, they do not use the SDKs
  12. directly. For all other libraries, especially, general purpose libraries
  13. (e.g. ``six``), our strategy is to make compatibility as broad and
  14. unrestricted as possible.
  15. 4. Add release notes to ``CHANGELOG.rst``. Also add last commit hash to
  16. changelog. List of commits can be obtained using
  17. ``git shortlog <last release hash>..HEAD``
  18. 5. Release to PyPi.
  19. (make sure you have run `pip install wheel`)
  20. First, test release with PyPI staging server as described in:
  21. https://hynek.me/articles/sharing-your-labor-of-love-pypi-quick-and-dirty/
  22. Once tested, run:
  23. .. code-block:: bash
  24. # remove stale files or wheel might package them
  25. rm -r build dist
  26. python setup.py sdist upload
  27. python setup.py bdist_wheel upload
  28. 6. Tag release and make a GitHub release.
  29. .. code-block:: bash
  30. git tag -a v1.0.0 -m "Release 1.0.0"
  31. git push --tags
  32. 7. Increment version number in ``cloudbridge/__init__.py`` to ``version-dev``
  33. to indicate the development cycle, commit, and push the changes.