Releasing

​

One-time setup (per project, done once by a maintainer)

1. On PyPI, create the clousight-bench project (or claim it) and add a Trusted Publisher:
   • Owner: clousight
   • Repository: clousight-bench
   • Workflow: release.yml
   • Environment: pypi
2. In the GitHub repo settings, create an Environment named pypi (optionally with required reviewers for a manual approval gate before publish).

​

Cutting a release

1. Update CHANGELOG.md: move the Unreleased section under the new version with today’s date. Never rename a released section back to Unreleased — once a version is tagged its section is history; new work goes in a fresh ## [Unreleased] heading above it. (This happened once, in #80: the shipped ## [0.5.0] heading was reopened as ## [Unreleased], so CHANGELOG.md claimed 0.4.0 was the latest release while v0.5.0 was published.)
2. Bump version in pyproject.toml — and keep the four other copies in sync: src/clousight_bench/__init__.py (RUNNER_VERSION, enforced by the wheel-smoke CI job), CITATION.cff (version + date-released), the README’s “N.N.N Developer Preview” line, and the assertions in tests/test_schema.py. The release workflow verifies the tag matches pyproject.toml.
3. Land those on main through a pull request.
4. Tag and push:
   git switch main && git pull
   # -a, not -s: this project's tags are annotated but unsigned (v0.5.0 is the
   # precedent). Use -s only if you have a signing key configured.
   git tag -a v0.2.0 -m "clousight-bench 0.2.0"   # tag must equal the pyproject version
   git push origin v0.2.0
   
5. The release workflow builds the sdist + wheel, runs twine check, and publishes to PyPI. Watch the Actions tab.
6. Create a GitHub Release from the tag and paste the changelog section.

​

Versioning