/release

Publish a new version of everos to PyPI. Publishing is automated: pushing a vX.Y.Z tag triggers .github/workflows/release.yml, which builds, smoke-tests, and uploads via PyPI Trusted Publishing (OIDC, no stored token) behind the release environment's manual-approval gate, then drafts the GitHub Release page from the CHANGELOG.

A release is not finished when PyPI accepts the upload: the GitHub Release page is drafted, never auto-published, and someone has to write its lead summary and click Publish.

Preconditions

• On main, up to date, with green CI (the tag builds from main's tree).
• Decide the version per SemVer: patch = fixes, minor = back-compatible features, major = breaking changes.

Steps

1. Bump the version    → pyproject.toml [project] version = "X.Y.Z"
   (single source; everos.__version__ reads installed package metadata)
2. Update CHANGELOG.md → move the Unreleased entries under a new
   ## [X.Y.Z] - <date> heading, and write the release page's prose here
   (lead paragraph + `### Upgrade` group, see "The release page")
3. Commit              → git commit -m "chore(release): vX.Y.Z"
4. Open a PR, merge to main after green CI
5. Tag main + push     → git tag -a vX.Y.Z -m "vX.Y.Z" && git push origin vX.Y.Z
6. Approve             → the release.yml run pauses on the `release`
   environment; a reviewer approves in the Actions run
7. Verify              → https://pypi.org/project/everos/X.Y.Z/
8. Publish the page    → the run leaves a DRAFT GitHub Release, already
   complete if step 2 was done properly. Read it once, click Publish.

The tag must equal the pyproject.toml version, the workflow refuses to publish on a mismatch. A stable tag with no matching ## [X.Y.Z] CHANGELOG section fails the release job for the same reason.

The release page