Skip to content
Ferrocat
⌘K

Release Verification

Checklist for validating a published Ferrocat release after automation completes.

This checklist verifies a real Rust-only ferrocat release after the publish workflow succeeds.

1. Confirm automation state

  • Open the latest Publish run and confirm the release-please job updated or closed the expected release PR cleanly.
  • For merged release PRs, confirm the same Publish run also completed the publish-rust job successfully.

2. Confirm workspace versions

  • Check crates.io for ferrocat-icu, ferrocat-po, ferrocat, and ferrocat-cli.
  • Confirm the published crates resolved to the same release version.
  • Confirm the workspace-only crates in the repo are also version-aligned with the published crates.
  • Confirm internal ferrocat* path dependencies in the crate manifests were updated to matching versions where applicable.
  • Confirm the GitHub release tag matches the published version created by Release Please.
  • For ferrocat-cli releases, confirm the ferrocat-<version>-x86_64-unknown-linux-musl.tar.gz asset and matching .sha256 file were uploaded to the GitHub release.

3. Confirm package viability

Before publishing, package the crates that are actually published:

cargo package -p ferrocat-icu -p ferrocat-po -p ferrocat -p ferrocat-cli --locked

Do not use cargo package --workspace as the release packaging check. The workspace also contains private publish = false crates for conformance fixtures and benchmarking. Cargo still validates those manifests during whole-workspace packaging, so the workspace-wide command is not the supported release gate.

4. Confirm install and docs surface

  • In a clean scratch project, run cargo add ferrocat.
  • Build a tiny smoke example that calls parse_po and parse_icu through the umbrella crate.
  • Download the x86_64-unknown-linux-musl CLI release archive when validating the binary channel, verify its .sha256 file, and run ferrocat --help.
  • Confirm docs.rs builds for ferrocat and that the README example still matches the published surface.
  • Confirm the crate READMEs published for ferrocat, ferrocat-po, and ferrocat-icu still describe the current public surface accurately.
  • Confirm the site API overview covers any new public APIs or semver-relevant behavior added in the release.
  • Confirm the published docs footer shows the release version from .release-please-manifest.json.
  • If the release included performance-sensitive changes, run or review the latest Benchmark Reports workflow artifact before publishing public benchmark claims.
  • Refresh dated quality snapshots when the release changes conformance counts, coverage thresholds, or the benchmark/coverage commands documented on the site.

5. Confirm repository metadata surface

  • Confirm LICENSE, SECURITY.md, and CODE_OF_CONDUCT.md are still present and match the current maintenance posture.
  • Confirm issue templates and the pull request template still reflect the current contributor workflow.
  • Confirm README badge links still point at the current crates.io, docs.rs, CI, and coverage surfaces.

6. Record outcome

  • If the release is good, record the workflow URL and version in the relevant status or changelog notes.
  • If publishing failed partway through, capture the exact crate, version, and workflow URL before retrying so the next release does not repeat the same blind spot.

7. Rollback guidance

  • If only the GitHub release failed, fix the workflow cause and rerun from the release commit.
  • If ferrocat-icu or ferrocat-po published but ferrocat failed, do not delete tags. Cut a follow-up release with the fix and let Release Please advance the version.
  • If a published crate is materially broken, use cargo yank for the affected version and note the yank in the release incident log.