Skip to content

release-process.md

Latest commit

 

History

History
65 lines (46 loc) · 1.67 KB

release-process.md

File metadata and controls

65 lines (46 loc) · 1.67 KB

Release process

Versioning

Follows SemVer. During 0.x.y:

  • 0.x.y. Patch / fix / docs
  • 0.X.0. New public surface or breaking change

Releases are tagged in git as vX.Y.Z and published on the GitHub Releases page.

Cadence

Beta. Ship as soon as something is ready. No fixed cadence.

Release checklist

  1. Update CHANGELOG.md. Move [Unreleased] items into the new version section.
  2. Bump version in package.json (and any other version-bearing file).
  3. Run local checks: 
    pnpm verify
pnpm api:contract -- --base-url https://nipcode.xyz
  4. Commit: git commit -m "release: vX.Y.Z"
  5. Tag: git tag -a vX.Y.Z -m "vX.Y.Z"
  6. Push: git push && git push --tags
  7. Create a GitHub Release for the tag with the changelog excerpt as body.
  8. Verify deploy is live on nipcode.xyz (Vercel auto-deploys on push).

Release artifacts

For CLI releases (when CLI ships), release sidecars are published under site/public/releases/:

  • .sha256 checksums
  • .sig signatures (cosign or minisign. TBD)
  • .sbom.json SBOM metadata (Syft output)
  • .provenance.json SLSA provenance metadata

Verification flow:

curl -fLO https://nipcode.xyz/install.sh
curl -fLO https://nipcode.xyz/install.sh.sha256
shasum -a 256 -c install.sh.sha256
bash install.sh

Rolling back

vercel rollback

Or, in git:

git revert <bad-commit>
git push

Post-release

  • Watch prod-monitor for 30 minutes after a release. It pings /, /docs, /api/search, /api/decision.
  • Sanity-check accounts and api_keys tables for any anomalies.