yamuse-release

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

1. Cargo.toml — set version.

2. 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.

3. 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.

4. 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.

5. verify — the whole matrix, not just --all-features:

   cargo fmt --check
   cargo clippy --all-features --all-targets     # must be silent
   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.

6. commit: chore(release): 0.X.Y, body pointing at the changelog.

7. push to main and confirm it landed.

8. publish: cargo publish --locked --all-features.

9. 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.