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¶
-
CIworkflow runs lint, tests, and build on pushes and PRs. [3] -
Docsworkflow builds and deploys the MkDocs site on pushes tomainand tag releases. [4] -
Releaseworkflow 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]