Release

Release

Prepare a new release by bumping the version and updating the changelog — or, with the review option, run a pre-release audit that surfaces inconsistencies and improvement ideas without changing anything.

self_update is a single crate; the version lives only in the top-level Cargo.toml.

Input

The argument selects the mode:

• review (or "release review", "review for release", "pre-release review") — run the Release review below. This is advisory only: it bumps nothing, edits no files, and makes no commit. Run it before cutting a release.
• A version string (e.g. 1.2.0) — run the Version bump flow (the numbered steps). If no argument is given and the intent is clearly to cut a release, ask which version.

If the user asks for a release review and then to proceed, run the review first and the version bump second.

Release review

A pre-release audit. Run it before cutting a release — especially a major version, since a major bump is the only window in which breaking API changes are acceptable. It does not bump the version, edit the changelog/README, or commit anything; it produces a report. It kicks off two complementary reviews, then synthesizes them.

A. Consistency review

Audit the public surface for lingering inconsistencies across the whole crate, not just the latest diff. Scope it to everything accumulated since the last released version.

Establish the baseline with plain, side-effect-free commands — run each separately rather than nesting a $(…) command substitution, so each invocation can be statically verified and auto-approved (a $(git …) substitution defeats static analysis and forces a prompt):

git describe --tags --abbrev=0    # last released tag
git tag --sort=-creatordate       # full tag list, newest first
git log --oneline -20             # recent commits — find the last "release" commit

Read the last-released version off the result, then diff against it explicitly, e.g.:

git diff v0.44.0..HEAD --stat     # substitute the real last-released ref

Cross-check the tag against the […] version headings in CHANGELOG.md and the most recent release commit in the log; if they disagree, use the last actually released commit (the one matching the newest released CHANGELOG section) as the diff baseline.

Check for:

• Naming parity — do sibling backends (github / gitlab / gitea / s3) share vocabulary on their builders? As of 1.0 the shared setters (url, target, identifier, auth_token, access_key, …) are unified via impl_common_builder_setters! and CommonConfig; flag any backend that re-introduces an odd-one-out name or diverges from the shared macro.
• Builder / entry symmetry — does every backend expose the same entry (configure()), the same fallible build(), and the same shared setters where they make sense?
• Trait-method parity — does the shared release-update trait in src/update.rs (and any helper traits) expose a consistent method set with consistent signatures (&self vs &mut self)?
• Feature-gate symmetry — is each public item gated behind exactly the features it needs? Are the reqwest/ureq and native-tls/rustls selections handled consistently, and is the coexistence model (both clients / both TLS providers can be enabled; reqwest and rustls win) surfaced clearly?
• Doc / CHANGELOG alignment — do the src/lib.rs docs, the [unreleased] CHANGELOG section, and any migration notes accurately describe the shipped API (named types, signatures, builder/setter names, feature gates)?

Delegate the correctness/idiom sweep to a pr-code-reviewer sub-agent fed the full release diff, and reason through the cross-backend parity items yourself — they need a whole-surface view the diff alone does not give.

B. API examination review

Run the consumer-experience-review skill. It builds a throwaway external consumer that depends on the crate the way a real user would and surfaces API gaps, naming inconsistencies, trait-import friction, and feature-flag dead-ends with compiler-verified evidence. This is the authoritative "what would a new user trip over" pass.