Releases

Every release is a signed tag on a commit that OpenHarnX verified READY and whose CI gate passed.

OpenHarnX 0.1.1

0.1.1, 2026-10-07#

The first release on PyPI. Release notes on GitHub.

Commit 2ea714cffcf425d0220d03d5d6802a32707acb05, signed tag v0.1.1, verified READY under srt and by the gate in GitHub Actions (run 37576131380).
The verifier is the same as 0.1.0. This release changes how you install it and how the project presents itself.

shell

uv tool install openharnx==0.1.1

In it: publishing to PyPI through trusted publishing (approved by the maintainer, no stored token, PyPI attestations); package metadata with links to the repository, documentation, issues and releases; a README that works as the PyPI page; CONTRIBUTING.md, ROADMAP.md and a trial-report issue template.

0.1.0, 2026-10-06#

The first release. Release notes on GitHub.

Commit 01626665a341812ded02c0559f5428c2e71d5ef1, signed tag v0.1.0. The gate passed on this exact commit in GitHub Actions under srt (run 37478954436), and its report carries a Sigstore attestation from that workflow.

In it: locked tests and acceptance tests, sandboxed verification, verdicts that say what they support, the review brief, the Claude Code Stop hook, the CI gate (GitHub Action, GitLab and Jenkins examples), signed evidence locally and in CI, and a fingerprinted checker interpreter.

How releases are made#

The commit is on main, verified READY under srt by an earlier installed OpenHarnX, with the GitHub Actions gate green.
version in pyproject.toml is set to the release number, verified READY and committed.
The commit is tagged with an annotated, signed tag and pushed.
The GitHub release names the full commit SHA, the changes and the release criteria met.
Publishing the release starts a workflow that builds the package and uploads it to PyPI through trusted publishing after the owner approves it. No token is stored.

The full procedure is docs/releasing.md. What comes next is on the roadmap.

Supported versions#

Only the latest release receives fixes.

Pin what you run#

A tag can be moved; a commit cannot. In CI, install by the commit SHA from the release notes and keep it in the workflow.