43. Release process¶
This page explains how to cut a release and what CI does for the documentation site and packages. For contributor setup, see Contributing and development.
43.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]
43.2 What CI does on push to main and on tag¶
-
CIworkflow runs lint, tests, and build on pushes and PRs. [3] -
Docsworkflow builds and deploys the MkDocs site on pushes tomainand on release tags. [4] -
Releaseworkflow builds sdist/wheel on tag releases and creates GitHub releases. [5]
43.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):
python -m build
python -m twine check dist/*
The build and release dependencies are declared in the development extras of pyproject.toml. [2]
43.4 How docs are published¶
The documentation site is built with MkDocs Material and deployed to GitHub Pages on pushes to main and on release tags. [8][4]