Release a version

A released version identifies an exact artifact. Do not change the bytes of an existing release.

Increase the version when bytes change

fruitful-plugin-build.json records each released bundle's SHA-256 under immutableReleases:

{
  "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 generated runtime bytes differ from that digest, increase version in the root fruitful-package.json. Keep the existing release's recorded digest. Bindings and Lexicon packages also have immutable versions. Dependency pins, such as ^1.0.0, specify which releases a Feed Package accepts.

Prepare the release

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

release rejects a stale bundle or stale generated Lexicon types. Run both generators before release. Examine their semantic changes through the validation procedure.

Examine the artifacts

<out>/
├── runtime/          # Manifests, bundles, and surfaces for devices
├── review/           # Fixtures, expectations, presentation examples, and evidence
└── attestation.json  # Digests that bind both artifacts

1. Make sure runtime and review artifacts share no files.
2. Make sure runtime/ contains no private review bytes.
3. Compare the actual artifact digests with attestation.json.
4. Make sure runtime code 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 tests cover publication, package proofs, and the release format. Also run affected workspace typechecks and format checks for changed files.

Follow the repository's contribution process for the definition. Publish, review, approve, promote describes registry publication from the merged inventory. A prepared release alone does not publish, install, or follow the feed.

Report the completion state

Use the following states in the handoff:

The authoring CLI currently has no consumer install or follow command. A preview, release directory, registry publication, or completed capture alone does not prove an active follow. If the connected tools cannot complete installation or following, state that limitation.

Include the following information without private content:

• The evidence scope, capture ID, and capture digest.
• The approved fixture digests, when applicable.
• The package name, version, and exact resolution digest.
• The validation result and meaningful changes to records or presentation.
• The preview case, clients examined, release location, and remaining warnings.
• The highest completion state the evidence supports.

If you used only stored fixtures, state that you did not test the current authenticated page. Keep captured HTML, private entry text, cookies, and tokens out of the report.

Reference: CLI.