Preparing a release

Release management

• We use semantic versioning MAJOR.MINOR.PATCH (i.e., briefly, major revision changes whenever the API changes in backwards-incompatible manner, MINOR changes for new features, PATCH changes for fixes that correct functionality; as long as MAJOR == 0, we can break the API with increasing MINOR.)

• Releases are cut from the master branch and tagged with MAJOR.MINOR.PATCH (note: the release tag determines the tag because we use versioneer, which obtains the release number from the git tag). We do from the master branch:

  1. git tag release-<major>.<minor>.<patch>
  2. python -m build (install python-build in a mamba env first)
  3. check with twine check dist/*
  4. twine upload dist/*

• Note: the tags need to be pushed to GitHub with git push --tags. (You can add text to the releases on GitHub.)

• Packages are published from the tagged (pip package, conda package (regro-cf autobot should make a PR once the PyPi package is up, can take a day), tar balls on GitHub); zenodo DOIs and snapshots are automatically minted.

• Docs are managed on ReadTheDocs and should automatically update (although it doesn't hurt to check and have docs build manually)