Rust Release Process
Relevant Rust source files
Cargo.tomlRELEASES.mdscripts/ci/publish-cargo-crates.shscripts/ci/check-crates-io-trusted-publishing.shscripts/ci/verify-published-registries.bashscripts/ci/publish-release-checksums.shscripts/ci/verify-github-release-attestation.bash
Nautilus crates share one workspace version and interdependent domain contracts. A release therefore coordinates version metadata, changelog/release notes, tests, package order, registry publication, GitHub assets, checksums, and attestations.
Preparation
Confirm a clean source revision, update the workspace version and release notes, run formatting/lint/test/security gates, and verify the supported feature/target matrix. Package checks must use the same manifests and includes that will be published; ignored local files are not part of the crate.
Publication order
Foundation crates must be available before crates that depend on them. The repository publication script encodes this ordering and registry verification. Do not hand-publish a middle crate from an inconsistent workspace revision.
Not every workspace crate is necessarily published. At the pinned revision nautilus-databento is a published adapter, while nautilus-interactive-brokers declares publish = false. A release guide must preserve that distinction.
Verification
After publication, verify registry versions and package contents, download and validate release assets, compare checksums, and verify attestations against the expected repository and commit. A successful upload response is not completion.
Rollback for an immutable registry is usually a corrective release rather than deletion. For a bad artifact, stop downstream promotion, document affected versions, and publish the smallest compatible correction through the same verified workflow.