Skip to content

RELEASING.md

Latest commit

 

History

History
38 lines (27 loc) · 1.66 KB

RELEASING.md

File metadata and controls

38 lines (27 loc) · 1.66 KB
Raw

Releasing COS

Only maintainers may publish an official COS release.

Release policy

A release tag uses three-part form vMAJOR.MINOR.PATCH. For protocol v0.2, the first release tag is v0.2.0. Published tags are immutable.

Checklist

  1. Confirm the protocol is no longer marked Draft, unless publishing an explicitly labeled pre-release.
  2. Set package.json to the exact three-part release version and set the specification Release Status to Released.
  3. Confirm the tag, package.json, Schema $id, specification metadata, and release notes agree.
  4. Ensure normative changes have design issues, review, fixtures, and changelog entries.
  5. Run npm ci, npm test, and npm run build.
  6. Review the generated single-page specification and chapter site.
  7. Run npm audit --audit-level=high.
  8. Create an annotated tag without moving any existing tag.
  9. Push the tag. The release workflow validates, packages, hashes, and creates the GitHub Release.
  10. Verify the GitHub Pages deployment and every attached artifact.
  11. Announce support status and known limitations.

For local packaging tests while the specification is Draft, use npm run prepare-release -- v0.2.0 --allow-draft. This flag is intentionally absent from the GitHub Release workflow.

Release artifacts

Each release contains:

  • generated single-page and chapter-based HTML;
  • normative JSON Schema;
  • valid and invalid fixtures;
  • Markdown specification sources;
  • license and changelog;
  • SHA-256 checksums.

Corrections

Do not rewrite a published release. Editorial or normative corrections are made on the default branch and published under a new tag according to VERSIONING.md.