Repository navigation
Release naming after the draft suffix: 0.3.0 as the first release without -draft, the conformance status value, and -rc.N for pre-releases #231
Description
Where the draft suffix lives
- The tags:
v0.1.0-draft,v0.2.0-draft, and the Policy companionpolicy-v1.0.0-draft.1(VERSIONING.md §Independently versioned Policy draft companion:-draft.N, "draft-only; it creates no stable identifier"). specVersionin every pack:0.2.0-draft. Readers compare it exactly; a conformance claim names one exact value.- The conformance manifests'
statusmember: the constantresearch-previewinconformance/manifest.json,conformance/evaluation/manifest.json, their schemas (conformance/manifest.schema.json,schema/conformance-manifest-0.1.0-draft.schema.json) and the table inconformance/evaluation/README.md. - The schema descriptions: "Research-preview structural schema" in
schema/judgment-pack-core.schema.json, the 0.1.0-draft copy and the Policy consumer schema. - VERSIONING.md:
0.xis named "the research period".
The wording outside these (README, FAQ, governance, the site, the companion documents' status sentences) now says draft or nothing (#229, #230).
The strategy proposed, for the maintainer's decision
0.2.0-draftstays what it is. Packs in the wild carry that exact string and readers compare it exactly; renaming it would be an incompatible change of the identifier of a released specification. The release notes and the tag keep their names.- The next release drops the suffix:
0.3.0, tagv0.3.0. VERSIONING.md changes the0.xrule from "the research period" to "pre-1.0: a0.xrelease may change incompatibly, with the change recorded in its release notes and a migration note forspecVersion". The-draftsuffix is retired for Core releases;0.3.0is the firstspecVersionwithout it. The conformance manifests'statusbecomes0.x(or the exactspecVersion), the schemas'constfollows, and the schema descriptions say "structural schema for<version>". - Pre-releases, when one is wanted, use
-rc.N(v0.3.0-rc.1), the SemVer form, marked as a GitHub pre-release; a tag without a suffix is a release. The Policy companion's-draft.Nroute is its own and keeps its name until the Policy format reaches its first release. 1.0.0is the standards claim, not the production claim: FAQ Q3 stays "not a standard yet" until the governance criteria (independent conforming implementations, production adopters, sustained outside contribution; GOVERNANCE.md) are met and recorded. Production use is stated now (FAQ Q46) and does not wait for1.0.0.- The runtime vendors the spec artifacts byte-exact at each spec release, so the
statusand description changes reach it with0.3.0; its acceptedspecVersionset gains0.3.0beside0.2.0-draft.
What this issue decides
The maintainer chooses: (a) the next version number (0.3.0) and the retirement of -draft; (b) the manifest status value; (c) whether a release candidate precedes 0.3.0. The edits are small and land in the 0.3.0 prep.
Activity
kikashy commentedon Oct 22, 2026
Decision (the maintainer's, 2026-10-22): accepted
0.3.0, tagv0.3.0: the firstspecVersionwithout the-draftsuffix.0.2.0-draftkeeps its name; the release notes explain the scheme change once. VERSIONING.md's0.xrule becomes: pre-1.0, a release may change incompatibly, with the change and aspecVersionmigration note recorded in its release notes.statusbecomes a maturity level, separate from the version:draftnow,candidatewhen the acceptance evidence is in,releaseat1.0.0; the ladder is written down in VERSIONING.md; the schemas'constand the schema descriptions follow ("structural schema for<specVersion>").v0.3.0-rc.1as a GitHub pre-release for about a week, for adopters' tooling to read the renamed status, thenv0.3.0.The Policy companion keeps its own
policy-v1.0.0-draft.Nroute until that format's first release.1.0.0is the standards claim, tied to the governance criteria; production use is stated now (FAQ Q46).Add the v0.3.0 notes and the status vectors named by the build (part of
Call RFCs draft, not research-preview, in the RFC process (#231 review)
Define 0.3.0 release naming and maturity status (#246)
kikashy commentedon Oct 22, 2026
Part one merged (pull request #246): the maturity ladder in VERSIONING.md, the status constants and schema descriptions, the 0.3.0 notes. The release stays open until the identifier re-pin (which files and the Runtime's vendoring are listed in #246's body), the release candidate
v0.3.0-rc.1and the tag.Add the frozen 0.2.0-draft schema copies and the historical Policy ch…
Re-pin Core surfaces to specVersion 0.3.0 (#248)
Support the exact Core 0.3.0 release candidate (#258)
kikashy commentedon Oct 25, 2026
RC packaging support merged in #258 at
e7d9fc02fa5b5e7a0b70ebbcb6b84db550736f8e; merged-head repository conformance is green. The separate complete pre-tag release review found one HIGH and two MEDIUM issues: changed historical schema identities, a missing historical evaluation-schema URL and an inaccurate migration promise. All are accepted for one correction batch in #259, where the full review and dispositions are recorded. Public RC tagging/publication remains on hold pending corrected checks and focused confirmation. No RC tag has been created; the accepted approximately-one-week public adopter period has not started.kikashy commentedon Oct 25, 2026
The single v0.3.0-rc.1 prerelease is now public, published 2026-10-25 14:25:28 UTC. This starts the accepted approximately-one-week adopter period; review feedback around 2026-11-01 14:25 UTC before deciding final publication.
The original signed tag and artifact source remain
495535f29a517dc6a36075b77238634011e7371e. Recovery checks, actual cryptographic provenance, unchanged asset identities and the completed independent correction reviews are recorded in #261. Core maturity remains draft;specVersionremains exact0.3.0. This is not the finalv0.3.0release, and staged Dialect preparation-verifier vectors remain excluded. This issue stays open for adopter feedback and the remaining final-release gates.Final notes: state how the release's checks are recorded, with no pla…
Make v0.3.0 the retained-column leaf's normative support distribution (…
Hold the final to RC2's published inventory; state the checks record …
Name v0.3.0 as the leaf's adoption release in the companion, Core, Di…
Prepare the v0.3.0 final: immutable notes, the retained-column leaf i…
kikashy commentedon Oct 29, 2026
Candidate feedback and disposition (the maintainer's, 2026-10-29)
Feedback received: none. No adopter commented on
v0.3.0-rc.1(published 2026-10-25) orv0.3.0-rc.2(published 2026-10-27), here or in a separate issue.Disposition: the maintainer shortens the candidate period and cuts
v0.3.0on 2026-10-29. That is four days after rc.1 and two days after rc.2, instead of the planned one week after rc.2.Why: no feedback is pending. The final changes no normative artifact relative to rc.2. Its leaf inventory is pinned to rc.2's published digest. The implementation finals waiting on this tag (runtime, runner and the Desk's next pin) are the release train's critical path.
What does not change: VERSIONING.md keeps "about one week of public RC availability" as the practice for later candidates. This is a recorded exception for 0.3.0, and the release notes' "Candidate period" section says so. Feedback that arrives after the tag goes to a new issue against
0.3.xor0.4.0.Date the 0.3.0 release and record the shortened candidate period (#231)…
kikashy commentedon Oct 29, 2026
Released: v0.3.0, tag signed at
27cb29bf13e4a2d58d69fe19c7ebfeb762b014fc, published 2026-10-29. Both archives verified againstchecksums.txtand their build attestations;release-identity.jsonnamesv0.3.0at that commit with maturitydraft.