We
are
all
part of
the
band

About » Releases

This explains how you can configure a Jazzband repository to be auto-released on PyPI whenever you create a Git tag and push it to GitHub.

Packaging

Since we’re currently aiming at Python projects primarily please make sure your project is able to be packaged as a Python package on PyPI. There is a great and extensive documentation in the Python Packaging Guide that should allow you to prepare your project accordingly.

We recommend using setuptools_scm for automatically deducing the version of the project package from Git – but setting the version manually in the setup.py works just the same.

Travis

Next you will want to follow Travis-CI’s documentation for how to do PyPI deployments.

In short:

When you’re ready to do a release to PyPI simply make sure to prepare all the code you’d like just as before (e.g. update AUTHORS, CHANGELOG, documentation), commit the changes, tag them with git tag and push the code to GitHub with git push --tags. If all goes according to plan you’ll see the release show up on PyPI automatically.

Versions and code names

When tagging releases using Git you need to make sensible decisions about which version number you use.

Jazzband follows the semantic release versioning scheme in which “semantic” means “correct for when a computer sees it” – not “nice to read for a human”. Don’t hesitate to release 1.0, or 2.0 or 41.5.12 for that matter. Do a 1.0 release as soon as your project is used in a real world application.

If you’d like to make statements about the importance of your releases attach a human readable release code name to your public announcments. Choose a theme that will allow you to pick one for every release, e.g. cat names. Or city names. Tree names. Color names. Anything that has lots of names.

No:

Happy to announce that we just released Useful Software 1.4!

Yes:

Happy to announce the “Cello” release (1.4) of our Useful Software!

How to decide for the version number?

Given a version number BREAKING.FEATURE.FIX increment…

  1. BREAKING when you make a backward-incompatible change to existing APIs
  2. FEATURE when you add a new feature without breaking backward-compatibility
  3. FIX when you fix a bug in an existing feature

Login to join