Skip to content

Releasing image-slash-star

Latest release: 0.1.3.

There is one Cargo crate and no npm or PyPI distribution. Releases use this repository's release.yml workflow and GitHub OIDC.

Prepare and tag

  1. Update the package version, changelog, documentation source-version field, and both workspace lockfiles through make release-lock-update.
  2. Read maturity and the public roadmap. Keep planned or unmeasured behavior explicit.
  3. Run make ci, including strict lint, contract checks, feature/target tests, source coverage, package extraction, rustdoc, and isolated consumers.
  4. Inspect the distributable archive and its licenses. Use make release-verify from a clean checkout for release acceptance.
  5. Commit and push to main only after the exact commit passes the Required CI checks ruleset. To keep direct pushes, first run CI on a codex/** branch, then fast-forward the same tested commit to main.
  6. Push a new annotated v<version> tag on the validated commit.

The alpha source-coverage floors are 59% lines, 46% branches, 52% functions, and 58% regions. Every executed test must pass. Full completion still requires make coverage-complete; neither a package release nor a floor pass closes the coverage goal.

Review publisher action updates

The crates.io authentication action is pinned to a reviewed commit. When its pin changes, review both the upstream source and committed distribution bundle, then update the exact revision check and its regression coverage in the same change.

Revision 1.0.6 at commit 3268eb4 keeps the action entrypoint unchanged and updates bundled Undici from 6.26.0 to 6.29.1. The Undici 6.29.1 release includes security fixes, including GHSA-xjj6-f33q-929c and GHSA-2m5v-pch6-74hx. The workflow policy accepts this exact action commit and rejects the previous and any unreviewed revision.

Publish and verify

The crates.io trusted publisher identifies repository appunni-m/image-slash-star, workflow filename release.yml, and environment crates-io. The dedicated crates.io upload job receives OIDC permission; it does not check out the repository or run Cargo, Python, Make, or other repository scripts. An unprivileged job builds and checks the candidate, then frames those exact archive bytes for the crates.io API. The publisher verifies the prepared request and the remote annotated tag before authentication, then uploads that request directly. Registry download and byte comparison run in a separate job without OIDC permission. No local login or long-lived registry token is used by subsequent releases. The GitHub attestation job requests OIDC separately for attestations. If a retry finds the same version already published with identical archive bytes, it skips the upload and continues to registry verification; different bytes fail closed.

The workflow builds and validates before publishing. It checks registry artifact identity and creates GitHub assets only after successful publication. The tag workflow also runs make coverage on the exact tagged source and blocks publication unless the aggregate report passes the current release floors. Its report and log are retained as llvm-coverage-release-<tag>. Use make release-registry-verify for a read-only candidate/registry comparison. Binary downloads must be hashed as archive bytes, not JSON redirect metadata.

Release 0.1.3 completed this flow. Its crate SHA-256 is 3e7755f83b15f0fc3f763276dc172ac21c6da153e9f5dc3abebbd456d91ac8b0. See Evidence for accepted source and test boundaries.

Recovery and immutable artifacts

Retry only the same source and unchanged artifacts after a transient failure. An uploaded registry version or released tag must never be overwritten. Changed source, packaging, or artifact bytes require a new version and tag. Verify which job actually failed before changing trusted-publisher settings. Protect v* tags with the active release-tag ruleset, which allows tag creation but blocks updates and deletion. The workflow checks cannot eliminate the brief race between a remote-tag check and an upload. The publisher rechecks the annotated tag against the triggering commit immediately before authentication and upload. The GitHub release job checks it again before attestation and release creation.

The completed local bootstrap target has been removed. The maintainer controls releases through repository review and tag permissions; no maintainer-succession guarantee or support SLA is implied.

Required source assets

AV1's reconstruction index and its five sidecars form a reproducible oracle set consumed by clean test checkouts. They can be regenerated from the exact licensed inputs and pinned dav1d/Pillow tools described in fixture provenance. Do not delete required oracle outputs while retaining tests that consume them.

The crate keeps public guides, generated capability tables, package examples, licenses, notices, and source needed by consumers. Internal release diaries and local benchmark output stay out of the package.

Documentation publication

Main documentation CI publishes GitHub Pages from this same repository, independently of registry versions. See documentation maintenance.

Refresh user documentation after publication

Wait for every registry job and the GitHub release to succeed, then run:

make docs-release-refresh
make docs-release-check docs-registry-examples

Review and commit the refreshed release record and installation blocks. The Documentation workflow checks freshness after a successful tag release and on its daily schedule. Keep source-candidate versions separate from published installation versions; do not send users to a version that is still building.