release: v0.8.0 — receipt spec, policy registry, open core - #110
Merged
Conversation
Rolls the Unreleased section into 0.8.0 and bumps pyproject to match, which is
what the Release workflow verifies before it will cut anything.
Three corrections came out of doing it, all of them cases of a version claim that
had stopped being true:
- install.sh still defaulted to 0.6.0, two releases behind, while its own comment
promised "the latest hardened tag". The one-line installer was quietly handing
people older code than every other install path on the project advertised. It
escaped the pin sweep because it interpolates v${VERSION} rather than spelling
the version out.
- docs/RELEASING.md told you to `git push origin main --tags`. main is protected
and requires its status checks, so that step cannot succeed — the documented
release process did not work. It now goes through a PR, and it says to move the
CHANGELOG heading, which the old text omitted even though the release notes are
extracted from it (a release cut without that step silently ships fallback text).
- CONTRIBUTING.md never mentioned policies, so the registry this release ships
had no contribution path pointing at it. Adding one is a single YAML file with
no test to write, because tests/test_policy_registry.py is parametrized over
every entry.
The 15 core@v0.7.0 pins move to v0.8.0. The `@v0.5.3 or later` and `@v0.1.3+`
floors are deliberately left alone — those state a minimum, not the current release.
Signetry Reviewer — 🟡 Needs human reviewA human should decide — the required check is pending; 1 advisory finding(s) to weigh. Deterministic gates (the authority)
Findings (1, 0 blocking)
MergeA human should review and merge.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cuts signetry-core v0.8.0: the published receipt spec, the policy registry, the
open-core licence change, and the placeholder-provenance fix.
CHANGELOG.md'sUnreleasedsection becomes[0.8.0] — 2026-09-01andpyproject.tomlmoves to0.8.0. The Release workflow refuses to cut anything ifthose two disagree, and it extracts the release notes from that heading — verified
locally: 23 bullets extract,
uv build+twine checkpass onsignetry_core-0.8.0.Three stale claims this surfaced
Cutting the release meant sweeping every version string, which is how these turned up:
install.shdefaulted to0.6.0— two releases behind, while its own commentpromised "the latest hardened tag". The one-line installer was handing people older
code than every other install path advertised. It escaped the pin sweep because it
interpolates
v${VERSION}instead of spelling the version out, which is exactly whyit drifted unnoticed.
docs/RELEASING.mddocumented a release that cannot happen. Step 3 wasgit push origin main --tags;mainis protected with required status checks, sothat push is rejected. The doc also never said to move the CHANGELOG heading — even
though the release notes are extracted from it, so a release cut by following the
doc would have shipped the fallback text instead of its own changelog.
CONTRIBUTING.mdnever mentioned policies. This release ships a six-policyregistry and a docs page, and there was no contribution path pointing at either.
Pins
15
core@v0.7.0→core@v0.8.0. The@v0.5.3 or laterand@v0.1.3+floors areleft alone on purpose — they state a minimum supported version, not the current release.
Integrations bump their
signetry-corepin after this lands, per the release train inSignetry/signetry.