Skip to content

Record v0.1.0-draft.1 identifier-correction republication#5

Merged
kikashy merged 1 commit into
mainfrom
chore/versioning-two-tags
Jul 23, 2026
Merged

Record v0.1.0-draft.1 identifier-correction republication#5
kikashy merged 1 commit into
mainfrom
chore/versioning-two-tags

Conversation

@kikashy

@kikashy kikashy commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Why

v0.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, and any implementation that pins a tag is forced to embed the temporary ones.

What

Prepares v0.1.0-draft.1 as 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 — new 0.1.0-draft.1 section. The Unreleased NOTICE entry rolls into it rather than being orphaned by the tag.

Why republish instead of re-pointing v0.1.0-draft

Re-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.1 has that tag and its base commit recorded in a digest lock.

Verified

  • spec/, conformance cases, and conformance/manifest.json are byte-identical between v0.1.0-draft and main (git diff v0.1.0-draft origin/main → empty for those paths)
  • The only difference is the $id member of the Core schema and the conformance manifest schema — 2 lines
  • 0.1.0-draft.1 > 0.1.0-draft per SemVer §11.4 (equal leading identifiers, larger field set wins)
  • 37/37 tests/ pass

specVersion is unchanged. No normative requirement changed.

Next

Once merged, tag main as v0.1.0-draft.1 — which triggers the release workflow to draft the immutable release.

🤖 Generated with Claude Code

…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
kikashy merged commit ef5f715 into main Jul 23, 2026
4 checks passed
@kikashy
kikashy deleted the chore/versioning-two-tags branch July 23, 2026 22:18
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant