SsuperslateDocs

Releases

Identify immutable product releases and rehearse a safe upgrade path.

Release and delivery contract

Product releases are immutable annotated Git tags and deterministic source artifacts. A mutable branch, local checkout, package version, deployment, or generated buyer repository is not a product release.

Versioning

The first approved commercial baseline is v1.0.0. Before it exists, the product remains unreleased. After v1.0.0:

  • patch releases preserve the supported product contract and contain compatible fixes;
  • minor releases add backward-compatible capability or supported-path improvements;
  • major releases require explicit buyer action to preserve an existing supported contract.

Release candidates use vMAJOR.MINOR.PATCH-rc.N. Internal v0.0.0-rehearsal.N tags may exist only in isolated rehearsal repositories; they are never customer releases, entitlement events, or public compatibility claims.

Required release inputs

Every commercial tag requires:

  • a clean commit that has passed main CI;
  • an annotated tag pointing at that exact commit;
  • a matching CHANGELOG.md heading;
  • docs/releases/<version>.md completed from the release-note template;
  • pinned Node, Bun, pnpm, Vite+, TypeScript, Postgres, and provider assumptions;
  • migration forward/backward/irreversible notes;
  • environment additions/removals/rotations;
  • known issues and support transition window;
  • root, real-Postgres, custom-buyer, package-native toolchain, audit, packaging, and previous-release upgrade proof.

The first commercial tag has no previous supported release. It still requires a full fresh-buyer proof. Every later tag requires release:rehearse-upgrade from the previous supported tag.

Verification commands

Run only from the clean commit carrying the annotated target tag and against a disposable database:

RELEASE_DISPOSABLE_DATABASE=1 \
DATABASE_URL='postgresql://app:app@localhost:5432/release_verify?sslmode=disable' \
pnpm release:verify -- v1.0.0-rc.1 v1.0.0-rc.0

Omit the second tag only for the first commercial baseline. The verifier refuses a dirty checkout, a lightweight/mismatched tag, missing notes, or a database not explicitly declared disposable.

The verifier:

  1. freezes dependencies and proves migration up → down → up;
  2. runs DB-enabled tests, checks, supported builds, package-native escape commands, and audit;
  3. creates and fully verifies a custom-scope/custom-brand buyer;
  4. packages the tagged source through Git attributes;
  5. rehearses an upgrade from the previous tag when supplied.

Artifact contract

release:package produces:

  • foundation-source-<tag>.tar.gz;
  • foundation-source-<tag>.tar.gz.sha256;
  • foundation-source-<tag>.manifest.json.

The tarball is git archive output compressed with timestamp-free gzip. Re-running the packager for the same tag produces the same bytes. The manifest records tag, commit, commit timestamp, artifact checksum, and toolchain pins. A checksum detects accidental change; it is not a cryptographic signature or proof of publisher identity.

The archive excludes:

  • the seller landing site and private planning;
  • historical Phase 2 instructions and internal dated author evidence;
  • Git history, dependencies, build output, runtime environment, evaluation runs, and release output.

It includes the buyer template, root/scoped agent rules, CI, buyer/commercial contracts, golden paths, create-app, and release/upgrade documentation.

Upgrade rehearsal

The deterministic rehearsal:

  • extracts both exact tags;
  • generates old/current buyers with the same name, scope, and brand;
  • refuses any modified or removed previous migration;
  • constructs a shared Git baseline, adds a buyer-owned product file, and merges the target foundation branch;
  • proves the buyer-owned file survives;
  • runs migration reversal, DB-enabled tests, frozen install, checks, all tests/builds, and audit.

This proves an unmodified reference plus a non-overlapping buyer change. It does not promise that arbitrary application customizations merge without conflict. Buyers must review conflicts using Upgrading.

Entitlement and access

CI artifacts are maintainer evidence, not customer fulfillment. After approval, the fulfillment system must copy the exact immutable artifact, checksum, manifest, notes, and license into the access-controlled release channel.

For each release grant, record:

  • order/license and authorized developer;
  • tag, commit, artifact checksum, and release publication timestamp;
  • entitlement type and updates_end_at;
  • grant/revocation/recovery events.

A buyer receives a release only when its publication timestamp falls within the recorded update entitlement, except an approved founding lifetime entitlement. Expiry never disables or revokes source already lawfully downloaded. Revoking managed access cannot erase a clone.

Never grant customer access to a mutable seller branch as a substitute for versioned delivery.

npm bootstrapper

The public superslate npm package is a source-delivery bootstrapper, not a copy of the paid foundation. Its stable package version must match an approved immutable source tag exactly:

superslate@1.2.3 → v1.2.3 → foundation-source-v1.2.3.tar.gz

Publish the npm version only after the matching private GitHub Release contains the source archive, SHA-256 file, and manifest produced by this contract. The CLI downloads all three through the buyer's existing authenticated GitHub CLI session and refuses malformed, mismatched, or modified artifacts. It must never download main, HEAD, another mutable branch, or an unverified archive.

The npm package remains private: true and version 0.0.0 in the pre-release checkout. Removing that guard, selecting the commercial version, creating the tag and release assets, and publishing with provenance are one reviewed release operation—not routine development edits.

Security and support

Security fixes use the same immutable release path, plus coordinated disclosure when needed. The current tag is supported. When an update requires buyer action, the prior tag receives the commercially defined transition window unless continued use is unsafe.

Do not publish exploit details, buyer data, secrets, private repository URLs, or provider credentials in release notes, manifests, CI logs, or artifacts.

On this page