Record v0.1.0-draft.1 identifier-correction republication#5
Merged
Conversation
…cation `0.1.0-draft` was tagged with schema `$id` values pointing at a temporary repository-hosted URL. The permanent `https://judgmentpack.org/schema/` form landed on `main` in #1, but no tag carries it, so no immutable release publishes the canonical identifiers. Republish the same specification version as `v0.1.0-draft.1` rather than re-pointing `v0.1.0-draft`, which would break the immutability guarantee this policy states and invalidate the provenance of artifacts already pinned to it. `specVersion` is unchanged. The prose specification, conformance cases, and conformance manifest are byte-identical between the two tags; only the two JSON Schema `$id` members differ. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: kikashy <kikashy@hotmail.com>
kikashy
added a commit
that referenced
this pull request
Jul 23, 2026
Reverts #5. ## What happened #5 prepared a second tag, `v0.1.0-draft.1`, to publish the permanent `https://judgmentpack.org/schema/` `$id` values under an immutable release. The tag was pushed and the release workflow **failed immediately**: ``` ValueError: release tag does not match the conformance specVersion ``` ## Why it cannot work `tools/build_release.py:52-67` binds the release tag to `specVersion` in three independent assertions, plus a fourth on release notes: | assertion | value | tag `v0.1.0-draft.1` | |---|---|---| | `conformance/manifest.json` → `specVersion` | `0.1.0-draft` | ✗ | | schema → `properties.specVersion.const` | `0.1.0-draft` | ✗ | | schema → `$id` path segment | `0.1.0-draft` | ✗ | | `releases/<tag>.md` exists | only `v0.1.0-draft.md` | ✗ | The design is **one tag per specification version, tag string equal to `specVersion`**. A second tag for the same version would require either bumping `specVersion` across the manifest, schema const, schema `$id`, all 47 conformance cases and the examples — announcing a revision when nothing normative changed — or relaxing an invariant that is doing real work. Reverting is better than leaving `VERSIONING.md` describing an arrangement that will never exist. ## State The tag has been deleted. No GitHub release was created — the run died at the build step — so per `VERSIONING.md` no immutable release was ever established, and nothing consumed it. ## Consequence `main` carries the correct permanent `$id` values; only the tagged `v0.1.0-draft` artifacts carry the temporary repository-hosted form. Implementations needing the permanent identifiers pin the commit until a future specification version is tagged. `judgment-pack-runtime`'s release gate already accepts a full-length commit digest as an immutable reference. ## Follow-up worth considering Correcting the tagged `$id` values properly means a future `specVersion` bump. Worth a decision on whether `0.1.1-draft` is warranted for that alone. ## Verified Restores the exact pre-#5 state (`git diff 4609d83` for both files is empty). 37/37 tests pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: kikashy <kikashy@hotmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
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.
Why
v0.1.0-draftwas tagged with schema$idvalues pointing at a temporary repository-hosted URL. The permanenthttps://judgmentpack.org/schema/form landed onmainin #1, but no tag carries it — so no immutable release publishes the canonical identifiers, and any implementation that pins a tag is forced to embed the temporary ones.What
Prepares
v0.1.0-draft.1as an identifier-correction republication of the same specification version.VERSIONING.md— the "exact tag" phrasing made two tags for one version self-contradictory. The immutability sentence is hoisted so it governs both tags, and the version↔tag mapping is stated explicitly.CHANGELOG.md— new0.1.0-draft.1section. TheUnreleasedNOTICE entry rolls into it rather than being orphaned by the tag.Why republish instead of re-pointing
v0.1.0-draftRe-pointing would break the immutability guarantee this very policy states, and would silently invalidate the provenance of artifacts already pinned to it —
judgment-pack-runtime@v0.0.1has that tag and its base commit recorded in a digest lock.Verified
spec/, conformance cases, andconformance/manifest.jsonare byte-identical betweenv0.1.0-draftandmain(git diff v0.1.0-draft origin/main→ empty for those paths)$idmember of the Core schema and the conformance manifest schema — 2 lines0.1.0-draft.1 > 0.1.0-draftper SemVer §11.4 (equal leading identifiers, larger field set wins)tests/passspecVersionis unchanged. No normative requirement changed.Next
Once merged, tag
mainasv0.1.0-draft.1— which triggers the release workflow to draft the immutable release.🤖 Generated with Claude Code