-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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.
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
version-bump check doesn't know a subcrate hasn't bumped on nightly if we've bumped it on beta #12347
Labels
A-infrastructure
Area: infrastructure around the cargo repo, ci, releases, etc.
C-bug
Category: bug
S-needs-design
Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Comments
weihanglo
added
C-bug
Category: bug
S-triage
Status: This issue is waiting on initial triage.
A-infrastructure
Area: infrastructure around the cargo repo, ci, releases, etc.
labels
Jul 11, 2023
I believe
cc @obi1kenobi |
weihanglo
added
S-needs-design
Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
and removed
S-triage
Status: This issue is waiting on initial triage.
labels
Jul 18, 2023
This was referenced Jul 21, 2023
bors
added a commit
that referenced
this issue
Jul 26, 2023
ci: rewrite bump check and respect semver ### What does this PR try to resolve? This ports `ci/validate-version-bump.sh` and #12200 to the new xtask `bump-check`. It also adds the ability to set the correct baseline revision when checking version bump. That is, it fixes #12347. In addition, this integrates the community tool `cargo-semver-checks`. SemVer violation can now be detected earlier. ### How should we test and review this PR? This PR extracts the registry query part from `xtask-unpublished` and removes other pars. I don't feel like we need it in the short term. For how it works, please the check doc comment in each function. One concern is that this check is still a required job for bors. I believe `@obi1kenobi` is quite responsive and willing to help if there is something wrong. So, waiting for an upstream fix won't be a problem for cargo. Also as a good citizen in the community, we can always contribute back. (Take it easy `@obi1kenobi,` don't be stressed out 🙂) <!-- homu-ignore:end -->
bors
added a commit
that referenced
this issue
Jul 26, 2023
ci: rewrite bump check and respect semver ### What does this PR try to resolve? This ports `ci/validate-version-bump.sh` and #12200 to the new xtask `bump-check`. It also adds the ability to set the correct baseline revision when checking version bump. That is, it fixes #12347. In addition, this integrates the community tool `cargo-semver-checks`. SemVer violation can now be detected earlier. ### How should we test and review this PR? This PR extracts the registry query part from `xtask-unpublished` and removes other pars. I don't feel like we need it in the short term. For how it works, please the check doc comment in each function. One concern is that this check is still a required job for bors. I believe `@obi1kenobi` is quite responsive and willing to help if there is something wrong. So, waiting for an upstream fix won't be a problem for cargo. Also as a good citizen in the community, we can always contribute back. (Take it easy `@obi1kenobi,` don't be stressed out 🙂) <!-- homu-ignore:end -->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-infrastructure
Area: infrastructure around the cargo repo, ci, releases, etc.
C-bug
Category: bug
S-needs-design
Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Problem
We've added
cargo unpublished
xtask andci/validate-version-bump.sh
to help the project to detect if a pull request has touched any subcrate and needs a version bump for it. This works well when there is no bump on beta branch. Bad thing happens when we already have a bump on the current beta but not yet published,cargo published
would assume we've already bumped that crate.In reality, we should consider crate version in beta branch as “published” and check the version bump against that instead of published one on crates.io. Every crate gets into beta branch of the 6 weeks release window should be considered as “published”.
Steps
In #12310, the check thought
crates-io
crate has been bumped. Actually it is required to update to 0.37.0, since 0.36.1 will be published with 1.72.0, but #12310 is targeted at 1.73.0. or 1.74.0 if merged.Possible Solution(s)
It is quite tricky to solve this. Subcrates are not necessary to follow the train release model with Rust and Cargo. However, there are some requirements we need to pay attention to
I don't have a good answer for the release model of subcrates, but here is a proposal that may make it more explicit:
crates-io
0.36.1 it would be0.36.1+1.71.0
, so that is pretty clear it is targeted to be released with Rust 1.71.0.crates-io@0.36.1
to0.37.0
, then we just bump it to0.37.0+1.71.0
. We then need a xtask automation to detect that on beta it has got a version bump so on nightly we need to adjust accordingly.Version
This is about project infra but let me record the point of time it happened.
The text was updated successfully, but these errors were encountered: