Release checklist
This page is for modelstamp maintainers. Merging a pull request into main
does not publish a package automatically.
Before the release
- Confirm that the intended changes are covered by tests and documented.
- Add user-visible changes under a new version in
CHANGELOG.md. - Update
project.versioninpyproject.toml. Installed package metadata is the source formodelstamp.__version__; do not hard-code a runtime version in the package source. - Update the human-facing
versionanddate-releasedfields inCITATION.cffto match the planned release. - Open a pull request. Wait for the required test matrix, build checks, and CodeQL analysis to pass, resolve review conversations, and obtain the required Code Owner approval.
- Merge the approved pull request into
main.
Publish
- Confirm that the Zenodo GitHub integration is enabled for the repository. Without it, publishing a GitHub release will not create the corresponding Zenodo archive and version DOI.
- Create a tag matching the version, for example
v0.1.1, on the release commit inmain. - Publish a GitHub release from that tag.
- Confirm that the
Publish to PyPIworkflow verifies the tagged commit is contained inmainand builds the distributions. - Review the pending
pypienvironment deployment and approve it. - Confirm the workflow succeeds, then install the exact version from PyPI in a clean environment and run a small import or save/load smoke test.
Protected v* tags cannot be updated or deleted. If a release is incorrect,
fix it in a new version; do not attempt to replace an existing PyPI artifact.
When no release is needed
Do not publish a new package solely for repository administration, CI hardening,
or a regenerated uv.lock that does not alter packaged runtime requirements.
Documentation-only changes need a release only when the updated documentation
must be included in the built distribution rather than published on the
documentation site.
TestPyPI remains available for an intentional pre-release validation. It is not part of every production release.