Skip to content

fix(release): detect in-proposal dependency major bumps #2200

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
iunanua merged 1 commit into from
Jul 7, 2026
Merged

fix(release): detect in-proposal dependency major bumps #2200

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions .github/workflows/release-proposal-dispatch.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -645,14 +645,17 @@ jobs:
jq . /tmp/major-bumps-input.json

# Run the audit in a throwaway worktree so extra worktrees / cargo metadata do not touch
# the job checkout. Check it out at the ref actually being released (the ephemeral release
# branch tip captured before version bumps), NOT github.sha: for a hotfix or older-ref
# release those differ, and auditing against current main could major-bump a crate for a
# dependency requirement change that is not present in the branch being released.
# the job checkout. Check it out at the proposal branch tip (HEAD) — the released ref plus
# this run's version bumps from the previous step. This is deliberate on both ends:
# - It includes the dependency-requirement rewrites cargo-release made in the previous
# step, so a dependency bumped to a new major IN THIS proposal propagates a major bump
# to its dependents (e.g. protobuf 3->4 forces its dependents major).
# - It is built from the released ref, NOT github.sha, so changes present only on current
# main (and absent from a hotfix/older-ref release) never trigger a spurious bump.
MAJOR_BUMPS_WT=$(mktemp -d "${RUNNER_TEMP:-/tmp}/major-bumps-wt.XXXXXX")
RELEASE_SHA=$(cat /tmp/release_head_sha)
PROPOSAL_SHA=$(git rev-parse HEAD)

git worktree add --detach "$MAJOR_BUMPS_WT" "$RELEASE_SHA"
git worktree add --detach "$MAJOR_BUMPS_WT" "$PROPOSAL_SHA"
Comment on lines +656 to +658

@chatgpt-codex-connector chatgpt-codex-connector Bot Jul 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Re-run major-bump audit after forced major bumps

When the selected crates contain a dependency chain such as A -> B -> C, this one-time snapshot is taken before the loop below applies any forced major bumps. If A's in-proposal major makes B major in this step, cargo release version -p B rewrites C's B requirement as well (cargo-release documents that it updates dependent crates in the workspace when changing versions), but C was already audited against B's pre-major manifest and can remain pending or patch/minor with major_bumps: []. The audit needs to iterate to a fixed point, or otherwise re-check downstream crates after each forced major bump, so chained in-proposal majors do not leave downstream manifests changed without the corresponding major release.

Useful? React with 👍 / 👎.

set +e
( cd "$MAJOR_BUMPS_WT" && "${WORKFLOW_SCRIPTS_ROOT}/major-bumps-level.sh" /tmp/major-bumps-input.json ) \
> /tmp/api-changes-with-major-bumps-pre-commit.json
Expand Down
Loading