Release a version

A release is the exact artifact a version resolves to forever. Producing one is mechanical; inspecting it is the point.

Bump the version when bytes change

Each package's version is immutable once released. fruitful-plugin-build.json records the bundle digest of every released version:

{
  "entrypoint": "authoring/src/hn-page-plugin.ts",
  "outfile": "plugin/hn-page-plugin.js",
  "immutableReleases": [
    { "version": "0.13.0", "sha256": "4295e0dc…" },
    { "version": "0.14.0", "sha256": "db50d6a3…" },
    { "version": "0.15.0", "sha256": "db50d6a3…" }
  ]
}

If plugin generate produces bytes that differ from the recorded digest for the current version, bump version in the root fruitful-package.json rather than overwrite a released digest. Bindings and Lexicon packages version the same way, and the Feed Package's pins (^1.0.0) say which releases it accepts.

Materialize it

yarn fruitful plugin generate feed-packages/<name> --write --json
yarn fruitful lexicon generate feed-packages/<name> --write
yarn fruitful plugin release feed-packages/<name> --out <temporary-directory>

release refuses a stale bundle or stale generated types, so the two --write steps come first.

Inspect it

<out>/
├── runtime/          # what devices download: manifests, bundles, surfaces
├── review/           # fixtures, expectations, presentation examples, evidence
└── attestation.json  # digests binding both

Check three things:

• runtime and review share no files;
• no private review bytes appear under runtime/;
• attestation.json names the digests you expect, and runtime artifact roles are only transform and capture-hooks.

Run the proofs

yarn turbo test --filter=workspace.packages.feed-package-runtime
yarn lint --changed
git diff --check

The runtime package's tests cover the publication and package proofs and the release format itself. Then open a pull request with the definition; publishing happens from the merged inventory, see Publish, review, approve, promote.

Reference: CLI.