Releases#

The versioning standard in mtools is pretty straight-forward. It follows a major.minor.micro version system. We decided to start mtools at version 1.0.0 as it was already pretty stable and usable at that stage.

Bug fixes and minor feature additions are released periodically as part of micro releases. Minor releases will include more significant changes, including interface changes. We’re not sure yet what a major release constitutes :-).

The development version has the suffix dev0 attached. For example 1.0.1-dev0 is the development version leading up to a 1.0.1 release.

Minor and major releases might have release candidates leading up to the final release. Those are marked with the suffix rcX where X is a number starting at 0. For example, version 1.2.0-rc2 is the 3rd release candidate for upcoming release version 1.2.0.

GitHub milestones and git tags are named with a prefix v, for example v1.0.1.

Releasing a new version#

  1. Create a release branch, named release-x.y.z where x.y.z is the version to be released.

  2. Increase the version in ./mtools/version.py from x.y.z-dev0 to x.y.z.

  3. Make sure tests are passing in Python 3.6, 3.7, and 3.8 via tox -re py36,py37,py38.

  4. Make sure documentation tests are passing via tox -re doc.

  5. Update README.rst and CHANGES.rst accordingly.

  6. Any other cleanup tasks.

  7. (optional) leave the release branch for a few days to give others a chance to test it before releasing.

  8. Run python3 setup.py sdist bdist_wheel to build the dist packages.

  9. Run twine upload dist/* to publish the new version to PyPI (if you have permissions, otherwise ask someone who does, e.g. @rueckstiess or @stennie).

  10. Merge the release branch into master.

  11. Merge the release branch into develop.

  12. Delete the release-x.y.z branch.

  13. Bump the version on the develop branch (in ./mtools/version.py) to x.y.(z+1)-dev0.