# Release checklist

This checklist does not publish packages or images automatically. Keep
`publish = false` unless a separate crates.io publication decision is made.

## Before the first public release

- Confirm rights to publish all project code and preserve upstream attribution.
- Establish the official public repository and enable and test GitHub Private
  Vulnerability Reporting. Update [SECURITY.md](../SECURITY.md) with the real link.
- Require CI checks on the protected main branch. Verify an actual successful
  run on the hosting platform; local tests do not prove hosted CI is enabled.
- Run the [development checks](development.md), dependency audit, license checks,
  and coverage measurement from a clean candidate checkout. The line-coverage
  target is 90%; record any shortfall as an unresolved release item, without
  excluding production files to improve the number.
- Review every security advisory. Fix affected dependencies with minimal
  compatible changes, or block release. Do not silently suppress advisories.
- Confirm no credentials, production inputs, repository state or internal
  verification data are tracked. Check documentation commands and links.

## Tag and artifacts

After the checks pass, replace `Unreleased` with the release date, review the
version and known limitations, and tag the exact tested commit. Rebuild source,
binary and container artifacts from that commit. Publish SHA-256 checksums,
build/toolchain details, dependency inventory (SBOM), and source revision with
the artifacts. Include project and third-party licenses in binary distributions.

Only Linux x86-64 has been validated for this candidate. Do not label other
architectures or operating systems supported without testing them. Pin and
record container base-image digests for the release build; mutable tags alone
are not sufficient to reproduce an image.

If runtime code or dependencies change, repeat end-to-end snapshot/delta and
artifact verification. Documentation-only changes do not establish new runtime
performance measurements; retain the revision associated with earlier results.

## Configuration documentation checks

Verify all four `docker/examples/*.toml` with the release binary's
`--check-config` and render each matching Compose file with `docker compose config`.
Confirm mandatory TOML, removed business flags/env overrides, text logging,
automatic versus fixed TA certificates, and operator-maintained TALs are
documented consistently. Validate containers need a writable parent for both
protocol state and the sibling TA cache. Configuration reload instructions must
recreate a container after replacing a single-file bind-mounted TOML.