Reusable Library Release Verification

Use this workflow before releasing or handing off a reusable library crate, especially when it has optional features, public APIs, or an explicit MSRV.

Guideline Routing

Always load the pages for classification, edition and MSRV, Cargo, lints, testing, CI tooling, and public API evolution.

Load error, documentation, unsafe, async, or observability pages only when those surfaces are part of the library API.

Workflow

1. Confirm the crate is a reusable library and identify its public API, feature flags, and declared MSRV.
2. Verify all features are additive. If features are intentionally incompatible, document the supported feature matrix before release.
3. Check that public dependency types are exposed only when they are part of the intended contract.
4. Run the default all-features verification commands.
5. Run dependency and supply-chain checks when the project has the tools installed.
6. Verify out-of-box behavior for the default feature set.
7. For published crates, run cargo semver-checks to detect accidental public API breaks and cargo publish --dry-run to validate the release artifact.
8. Record any MSRV bump, public API break, new optional dependency, or feature behavior change in release notes or the changelog.

Default Verification

Use --workspace for every library crate or -p crate-name for one crate in a mixed workspace. Replace the illustrative +1.85.0 with the declared rust-version.

If the project intentionally maintains doctests, add:

cargo test --doc --workspace --all-features

Feature Matrix

Use --all-features by default. For intentionally incompatible features, replace it with a documented matrix of supported combinations:

cargo check --workspace --all-targets --no-default-features
cargo check --workspace --all-targets --features serde
cargo check --workspace --all-targets --features tokio
cargo check --workspace --all-targets --features "serde tokio"

Keep the matrix small; reconsider features that produce a large combination surface.

Dependency Checks

When the project has the tools installed, run:

cargo audit
cargo deny check
cargo machete

Treat these as release gates for published crates when the project has adopted them. For internal libraries, use them when dependency churn, public dependency exposure, or supply-chain risk is material.

Semver and Artifact Checks

For published crates, detect accidental public API breaks and validate the release artifact:

cargo semver-checks
cargo publish --dry-run

Install the checker once with cargo install cargo-semver-checks --locked. Use cargo package instead of the dry-run publish when the crate is not published to a registry. Treat any semver-major finding as either a bug to fix or an intentional break to record in step 8.

Avoid

• Do not release a library after checking only the default feature set when optional feature-gated code changed.
• Do not use --all-features as a substitute for documenting intentionally incompatible feature combinations.
• Do not let a dependency update raise MSRV without making that decision explicit.
• Do not add release-only verification commands that are never run locally or in CI.
• Do not require security or dependency tools for every tiny internal crate unless the project has adopted those gates.