Skip to content

SPEC_RELEASE_PROCESS.md

Latest commit

 

History

History
62 lines (55 loc) · 3.5 KB

SPEC_RELEASE_PROCESS.md

File metadata and controls

62 lines (55 loc) · 3.5 KB
Raw

Spec-Only Release Process

This repository is the canonical public source for reviewed IICP protocol text, intent registry state, and conformance fixtures. It is not a blind mirror of an implementation worktree.

Promotion procedure

  1. Gather current implementation evidence and the corresponding approved working specification changes. A proposed change must distinguish deployed behavior, draft behavior, and research.
  2. Update the candidate protocol text, registry, fixtures, and conformance rows together in this repository. Semantic profiles and experiments stay marked draft until independently implemented and reviewed.
  3. Update spec/v1.9/release-integrity-manifest.json only after review, using the exact digests of the canonical candidate artifacts.
  4. Run tools/check_spec_release_integrity.py, the fixture gates, and the relevant cross-implementation tests. A changed digest without a reviewed manifest update is a release blocker.
  5. Commit one coherent canonical spec change. Consumer repositories may link to this source or carry a clearly labeled synchronized reference; they MUST NOT silently overwrite canonical text through a generic copy script.
  6. Bump the Protocol Suite version only through its explicit versioning process. A draft profile or fixture update does not by itself ratify a suite release.
  7. Build the release archive from a clean detached tag. Publish only immutable assets with SHA-256 checksums; never rebuild or replace an existing tag.
  8. Run tools/check_public_artifact_closure.py. A release or standards-review input that depends on a private repository, missing local file or workstation path is not portable and MUST NOT be published.

Promotion checklist

  • Classify every changed artifact as research, pre-normative, or ratified.
  • Link implementation and conformance evidence for registry or normative changes.
  • Update schema and fixture digests in the same reviewed change.
  • Run both release-integrity and profile-fixture gates in the pull request.
  • Record compatibility, deprecation and successor behavior where applicable.
  • Ratify only after the required independent implementations pass the pinned fixture; otherwise retain the artifact's draft status.
  • Verify that status terms follow SPEC_STATUS.md and version axes follow VERSIONING.md.
  • Recheck every external registry claim immediately before publishing.
  • Confirm that the archive contains its root license, governance, security, contribution and continuation instructions.
  • Run python3 tools/check_public_artifact_closure.py --all-public to catch stale private dependencies elsewhere in the tracked public research and documentation corpus before tagging.

Boundaries

  • Current executable behavior can expose a contradiction in historical prose; record it and propose the correction. It cannot override a released normative contract or retroactively reinterpret wire behavior.
  • Registry entries require implementation evidence and payload/schema review.
  • Base-frame changes require an independent compatibility, malformed-input, and cross-implementation evidence package. Semantic profiles are preferred.
  • Website and implementation-repository documentation are public references, not substitutes for this canonical source.
  • Public technical research records the evidence and reasoning behind product decisions. Private development methodology is neither normative evidence nor a release dependency. The boundary is defined in docs/governance/public-artifact-boundary.md.