fix(ci): stop clap_usage changes from majoring usage-lib and usage-cli

[jdx]

#744 proposes v5.0.0 for usage-lib and usage-cli — hours after v4.0.0 shipped, with no source change in either crate. This fixes the cause, so it stops being regenerated.

Why v5

tasks/release-plz computes one version for the whole repo:

version="$(git cliff --bumped-version)"                  # reads every commit
cargo set-version "${version#v}" --exclude clap_usage    # applies to all but clap_usage

#743 was feat(clap_usage)!:. git-cliff saw the ! and majored the repo; set-version then applied 5.0.0 to every crate except the one that actually broke. So the two crates that didn't change get a major, and clap_usage gets nothing.

Scoped to the crates the version is actually set on, there is nothing to bump:

$ git cliff --bumped-version --include-path 'lib/**' --include-path 'cli/**'
WARN git_cliff > There is nothing to bump
v4.0.0

$ git log --oneline v4.0.0..HEAD -- lib cli
(empty)

Which is correct — neither crate has changed since v4.0.0.

Three changes

Scope the bump and changelog to lib/ and cli/. The version now reflects the crates it's set on.

Exit before opening a release PR when the bumped version equals the current one. Without this the corrected calculation would keep reopening a PR that bumps nothing — and it's why #744 can't just be closed today: the next run recreates it. With this, closing it sticks.

Publish clap_usage when its manifest is ahead of crates.io. The publish path only ever ran:

cargo publish -p usage-lib
cargo publish -p usage-cli

clap_usage isn't there, which is why it sat unpublished at 2.0.3 from 2025-01 until now while the workspace built against a far newer version — and why the trusted-publisher config for it has never been exercised. Its version stays hand-managed, so the check is against the crates.io index rather than the usage-lib tag, and it publishes in dependency order (usage-lib → clap_usage → usage-cli).

breaking_always_bump_major = true is deliberately left alone. The policy is right; it was being applied to the wrong crates.

Dry run

$ usage_dry_run=1 mise run release-plz
Releasing clap_usage 4.0.0
No usage-lib/usage-cli changes since v4.0.0; nothing to release

Exactly the two intended outcomes: clap_usage 4.0.0 finally ships, and no spurious v5.

After merging

The next release-plz run will not recreate #744, so it can be closed. clap_usage 4.0.0 publishes through trusted publishing on that run.

This PR was generated by an AI coding assistant.

---

Note

Medium Risk
Changes release tagging, changelog generation, and crates.io publish order; mistakes could skip needed releases or publish the wrong crate version.

Overview
Fixes release automation so breaking clap_usage commits no longer force a major bump on usage-lib / usage-cli when those crates did not change.

Version and changelog from git cliff are now limited to lib/** and cli/**, matching where cargo set-version applies. If the bumped version equals the current usage-lib version, the script exits without opening a release PR, so empty v5-style bumps stop recurring.

Adds publish_clap_usage_if_needed: compares the manifest version to crates.io and publishes clap_usage after usage-lib (and again on the tag path when the workspace is already released), since that crate was previously never published by this script.

^{Reviewed by Cursor Bugbot for commit cee8990. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Warning

Review limit reached

@jdx, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 4ef9fc26-ca86-4233-bd9f-843b7b646f31

📥 Commits

Reviewing files that changed from the base of the PR and between 6fa65f8 and cee8990.

📒 Files selected for processing (1)

• tasks/release-plz

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a028da7. Configure here.}

[greptile-apps]

Greptile Summary

This PR adjusts release automation to separate clap_usage publishing from usage-lib and usage-cli version calculation.

• Publishes clap_usage when its manifest version is absent from crates.io.
• Scopes git-cliff version and changelog generation to lib and cli.
• Stops before creating an empty release PR when the scoped version is unchanged.

Confidence Score: 3/5

The PR is not yet safe to merge because clap_usage can still be published before its newly published usage-lib dependency is available in the crates.io index.

The script invokes the two cargo publish commands consecutively, so normal registry propagation delay can make clap_usage dependency validation fail, aborting the release before usage-cli publication and tag creation.

Files Needing Attention: tasks/release-plz

Important Files Changed

Filename	Overview
tasks/release-plz	Adds scoped release calculation and clap_usage publication, but the attempted dependency ordering still lacks the registry-availability wait required before publishing clap_usage.

_{Reviews (2): Last reviewed commit: "fix(ci): publish clap_usage in dependenc..." | Re-trigger Greptile}

[jdx]

Both findings were real; fixed.

clap_usage published before usage-lib (cursor, and greptile independently) — correct, and it would have been worse than a failed clap_usage publish. It depends on usage-lib at the workspace version, so on a release where both advance, cargo rejects the publish for an unpublished dependency and set -e aborts the script before usage-lib goes out at all. A release that half-fails at the first step.

Now a function called in dependency order — usage-lib → clap_usage → usage-cli — and called once more on the path where usage-lib is already released and only clap_usage is behind. That second call is today's situation, and without it clap_usage would stay stuck until the next lib release.

Changelog bump not path scoped (cursor) — also correct. I scoped --bumped-version and the dry-run changelog but missed git cliff --bump -o CHANGELOG.md and the PR body, so a clap_usage breaking commit could still drive the changelog to a major while cargo set-version applied the scoped version — mismatched artifacts in the same release. All four git cliff calls are scoped now.

Dry run on the current state is unchanged and still what we want:

Releasing clap_usage 4.0.0
No usage-lib/usage-cli changes since v4.0.0; nothing to release

shellcheck tasks/release-plz is clean.

This comment was generated by an AI coding assistant.