33. Skip to content

33. Release process

This page explains how to cut a release and what CI does for docs and packages. For contributor setup, see Contributing and development.

33.1 Tagging scheme vX.Y.Z

Release tags follow semantic versioning in the form vX.Y.Z. The version source of truth is src/modssc/__about__.py, wired through tool.hatch.version in pyproject.toml. [1][2]

33.2 What CI does on push to main and on tag

  • CI workflow runs lint, tests, and build on pushes and PRs. [3]

  • Docs workflow builds and deploys the MkDocs site on pushes to main and tag releases. [4]

  • Release workflow builds sdist/wheel on tag releases and creates GitHub releases. [5]

33.3 How to cut a release

1) Update src/modssc/__about__.py and CHANGELOG.md for the new version. [1][6]

2) Commit changes and create a tag:

git tag vX.Y.Z
git push origin vX.Y.Z

3) GitHub Actions will run the release workflow to build artifacts and publish or attach them. [5]

Optional local pre-flight (build + twine check):

make release-prep

The Makefile targets are defined in Makefile. [7]

33.4 How docs are published

Docs are built with MkDocs Material and deployed to GitHub Pages on push to main and on tag releases. [8][4]

Sources
  1. src/modssc/__about__.py
  2. pyproject.toml
  3. .github/workflows/ci.yml
  4. .github/workflows/docs.yml
  5. .github/workflows/release.yml
  6. CHANGELOG.md
  7. Makefile
  8. mkdocs.yml