Publish

Publishing a new version

Publication to PyPI is automated via GitHub actions.

Generally, to publish new features quickly, use a pre-release (-rc) version. Stable releases should be done less frequently (after several months), since for these we want to collect a good amount of new features. Also, documentation will be kept, and we might need to keep supplying bugfixes for these. Bug-fix versions should be published ASAP, but have minimal invasive changes compared to the stable release they belong to.

Preparation

• Make sure the example notebooks used for documentation are up-to-date, since they are deployed as-is
• Update the __version__ string in xplt/__init__.py to e.g. 0.1.0 or 0.2.4-rc1, see here for formats
• Create a PR into main
• When releasing a major or minor version: Create a branch main-* from main for future bug fixing of the previous version (e.g. main-1.2 when releasing 1.3.0)

Release

• Merge the PR 🚀
• Add/update the GitHub release
  • For release-candidates, create a GitHub pre-release and then keep updating it until it becomes stable
  • For major or minor releases, ensure the GitHub release documents all changes and additions since the previous version, then change it from "pre-release" to "latest"
  • For bugfixes, edit the corresponding GitHub release (update notes and associated tag)
• CI creates a matching tag via the Release trigger workflow
  ⚠ This automatism is temporarily disabled, please trigger it manually or create a tag manually or via the GitHub release. The tag must be of the form "v" + version string from xplt/__init__.py.
• CI builds and publishes the package to test.pypi.org
• CI builds the documentation and pushes it to the gh-pages branch, from where it is published on GitHub Pages
• CI publishes the package to pypi.org