Making a release

A release takes two pull requests, one on each side of publishing it. The version in pyproject.toml is already the one being released, since the previous release’s post-release pull request set it.

1. Build the changelog

On a pre_release branch, assemble the changelog entries into CHANGELOG.md, with the release version and the day you will publish it:

towncrier build --version 2.0.0-beta4 --date "October 6th, 2026"

This writes a dated # v2.0.0-beta4 (October 6th, 2026) section at the top of CHANGELOG.md and deletes the entry files it read. Commit both, open a pull request titled Pre-Release 2.0.0-beta4, and read the assembled section to check the entries hold up as a list. Run towncrier build --draft --version 2.0.0-beta4 first to preview it without touching any files.

The pull request adds no changelog entry of its own, so the detect-changelog-entry check fails on it; that check is not required to merge.

2. Publish

Merge the pull request, then publish a GitHub release tagged v2.0.0-beta4 at that merge commit, so the release holds exactly the entries the build read. Use the new CHANGELOG.md section as the release notes. Publishing the release runs auto-publish.yml, which builds the package from the tagged commit and uploads it to PyPI.

3. Bump the version

On a post_release branch, bump version in pyproject.toml to the next version and open a pull request titled Post-Release 2.0.0-beta4. Every run records the GuPPy version that produced it in GuPPyParamtersUsed.json, so the bump makes runs made from main report the version in development rather than the one already released.