| name | yamuse-release |
| description | Use when cutting a release of the yamuse crate — bumping the version, writing the changelog entry, running the verification matrix, publishing to crates.io and tagging. Also use when asked to "publish", "release", "ship a version" or "push to crates.io". |
releasing yamuse
a crates.io publish cannot be undone. a version can be yanked, which stops new
dependants resolving it, but the files stay up forever and the number can never be
reused. everything below happens before the upload for that reason.
picking the number
pre-1.0, so 0.MINOR.PATCH and the minor is the breaking one:
| the change | the bump |
|---|
| anything a caller must edit to keep compiling | 0.X+1.0 |
| a new public item, no existing signature touched | 0.X.Y+1 |
| documentation, comments, tests only | 0.X.Y+1 |
adding a field to a public struct with public fields is breaking here — those
structs are constructed with ..Default::default() on purpose, and that syntax
still names the type. RetryPolicy gaining retry_after_max in 0.3.0 broke every
literal construction; that is the shape to watch for.
the sequence
-
Cargo.toml — set version.
-
CHANGELOG.md — a new section at the top, dated, with ### added,
### fixed, ### changed as needed. every breaking item starts with
**breaking.** and says what the caller has to do, not just what changed.
a doc-only release says so in one line under the heading.
-
README.md and README_ru.md — the yamuse = "0.X" line, but only when
the minor changed. a patch bump needs no readme edit, since "0.3" already
resolves to it.
-
refresh the lockfile: cargo check --all-features. the lockfile carries
the crate's own version, and CI runs --locked, so a stale one fails the build
rather than the release.
-
verify — the whole matrix, not just --all-features:
cargo fmt --check
cargo clippy --all-features --all-targets
RUSTDOCFLAGS="-D warnings" cargo doc --all-features --no-deps
cargo test --all-features
cargo test
cargo test --no-default-features --features rustls-tls
cargo test --no-default-features --features rustls-tls,download
cargo test --no-default-features --features rustls-tls,realtime
cargo test --no-default-features --features rustls-tls,tracing
cargo test --no-default-features --features native-tls,full
cargo publish --dry-run --locked --all-features
a feature-gated item referenced unconditionally shows up in exactly one of
those columns and nowhere else, which is why the middle ones exist.
-
commit: chore(release): 0.X.Y, body pointing at the changelog.
-
push to main and confirm it landed.
-
publish: cargo publish --locked --all-features.
-
tag vX.Y.Z and push the tag — after the publish, so a failed upload does
not leave a tag claiming a release that does not exist.
msrv
declared 1.85 in Cargo.toml, and CI runs the tests on exactly that. the trap is
that the local toolchain is much newer, so a feature stabilised after 1.85
compiles fine here and fails there. let-chains (if let Some(x) = y && cond)
are the one that has already bitten: stable from 1.88. write it as
y.is_some_and(|x| cond) instead.
if a release genuinely needs a newer feature, raise rust-version in the same
commit and say so in the changelog — an msrv bump is a breaking change for
anyone pinned to an older toolchain.
after publishing
docs.rs builds from the uploaded crate with --all-features; it usually appears
within a few minutes. docs/ is excluded from the package, so any readme link
into it must be an absolute github url or it 404s on crates.io.
