fix(update)!: Remove unstable --breaking - #17333
Merged
Merged
Conversation
Tor did a lot of great work on this within the constraints they had. The problem is what they uncovered through development: challenges with the current model for `update` and what I at least see as the ideal model for `update --breaking` (rust-lang#14259). I think we need to more closely examine the semantics of `cargo update` to understand what we want out of both. I also think seeing `uv lock` opens up new design possibilities that give us some more flexibility. We don't have to restrict ourselves to the interface of `cargo update` but can deprecate `cargo update` in favor of a `cargo lock upgrade` and add a `cargo upgrade` command. This is in enough of a half-working state, that I think its fine to push people back to `cargo upgrade` that are using it. The tracking issue is fairly quiet. By removing this, we also simplify discussion of expectations of other features that overlap, like min-publish-age. Technically, support in `--breaking` for min-publish-age wouldn't block min-publish-age but it represents one more thing we need to track and do to get it ready for stabilization. The references to this that I did find are: - https://stackoverflow.com/questions/78514306/how-do-i-tell-cargo-to-update-dependencies-beyond-the-current-versions-of-my-pro/78514408 - https://github.com/thewh1teagle/vibe/blob/main/docs/building.md#update-packages - A handful of crates with this in their justfile, like https://docs.rs/crate/pmtiles/0.20.0/source/justfile Closes rust-lang#14259 Closes rust-lang#14140 Followup: rust-lang#12425 needs to be updated to reflect this
Collaborator
|
r? @weihanglo rustbot has assigned @weihanglo. Use Why was this reviewer chosen?The reviewer was selected based on:
|
rustbot
added
A-cli
weihanglo
approved these changes
Aug 8, 2026
Member
|
@rfcbot fcp merge T-cargo tl;dr: New tools has brought new ideas and possibilities. We can step back a bit and rethink a better interface The downside is while See the PR description for details. |
Collaborator
|
@weihanglo has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rust-rfcbot
added
proposed-final-comment-period
weihanglo
reviewed
Aug 8, 2026
epage
force-pushed
the
breaking-breaking
branch
from
August 10, 2026 17:09
da52e81 to
31bd551
Compare
This comment has been minimized.
This comment has been minimized.
epage
commented
Aug 10, 2026
|
|
||
| ## update-breaking | ||
|
|
||
| The `cargo update -Zunstable-options --breaking` flag has been removed in 1.99-nightly. |
Contributor
Author
There was a problem hiding this comment.
Needs updating if this slips into the next release
Member
There was a problem hiding this comment.
Likely to slip, though if it gets enough signoff today I'll just merge this. Doesn't need to wait 10 more days.
epage
added a commit
to epage/cargo
that referenced
this pull request
Aug 10, 2026
To ensure dependencies have had a chance to be scanned, a user can set:
```toml
[registry]
global-min-publish-age = "7 days"
```
To force a critical update through, a user can
```console
$ CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p foo
```
That will be preserved within the lockfile.
To ensure users can observe what is going on and address concerns,
- Locking messages notify of:
- That min-publish-age is in use and what the age is if there is a
single one
- a newer, unpicked version is available and its age
- a version is being used that is incompatible with min-publish-age
(either through `allow` or an unchange dep shown through `-v`)
- Error messages notify of:
- a newer, unpicked version is available and its age
- a compatible version requirement to downgrade to
- how to use `CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE`
Items from the tracking issue:
- `deny` precedence between this and `incompatible-rust-version`: we can
always adjust this over time
- the `registry.min-publish-age` / `registries.*.min-publish-age` precedence rule: mimics credential providers
- `cargo install` behavior
- there was some confusion over what was being stabilized due to edits
that happened during the FCP that weren't noticed
- `resolver` is defined as not affecting `cargo install` which this
preserves, just like `incompatible-rust-version`
- `cargo update --breaking`: this feature is being stabilized first and
the other is being considered for removal (rust-lang#17333)
Fixes rust-lang#17009
epage
force-pushed
the
breaking-breaking
branch
from
August 12, 2026 18:59
31bd551 to
16a1c5b
Compare
Collaborator
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
epage
added a commit
to epage/cargo
that referenced
this pull request
Aug 12, 2026
To ensure dependencies have had a chance to be scanned, a user can set:
```toml
[registry]
global-min-publish-age = "7 days"
```
To force a critical update through, a user can
```console
$ CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p foo
```
That will be preserved within the lockfile.
To ensure users can observe what is going on and address concerns,
- Locking messages notify of:
- That min-publish-age is in use and what the age is if there is a
single one
- a newer, unpicked version is available and its age
- a version is being used that is incompatible with min-publish-age
(either through `allow` or an unchange dep shown through `-v`)
- Error messages notify of:
- a newer, unpicked version is available and its age
- a compatible version requirement to downgrade to
- how to use `CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE`
Items from the tracking issue:
- `deny` precedence between this and `incompatible-rust-version`: we can
always adjust this over time
- the `registry.min-publish-age` / `registries.*.min-publish-age` precedence rule: mimics credential providers
- `cargo install` behavior
- there was some confusion over what was being stabilized due to edits
that happened during the FCP that weren't noticed
- `resolver` is defined as not affecting `cargo install` which this
preserves, just like `incompatible-rust-version`
- `cargo update --breaking`: this feature is being stabilized first and
the other is being considered for removal (rust-lang#17333)
Fixes rust-lang#17009
epage
added a commit
to epage/cargo
that referenced
this pull request
Aug 12, 2026
To ensure dependencies have had a chance to be scanned, a user can set:
```toml
[registry]
global-min-publish-age = "7 days"
```
To force a critical update through, a user can
```console
$ CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p foo
```
That will be preserved within the lockfile.
To ensure users can observe what is going on and address concerns,
- Locking messages notify of:
- That min-publish-age is in use and what the age is if there is a
single one
- a newer, unpicked version is available and its age
- a version is being used that is incompatible with min-publish-age
(either through `allow` or an unchange dep shown through `-v`)
- Error messages notify of:
- a newer, unpicked version is available and its age
- a compatible version requirement to downgrade to
- how to use `CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE`
Items from the tracking issue:
- `deny` precedence between this and `incompatible-rust-version`: we can
always adjust this over time
- the `registry.min-publish-age` / `registries.*.min-publish-age` precedence rule: mimics credential providers
- `cargo install` behavior
- there was some confusion over what was being stabilized due to edits
that happened during the FCP that weren't noticed
- `resolver` is defined as not affecting `cargo install` which this
preserves, just like `incompatible-rust-version`
- `cargo update --breaking`: this feature is being stabilized first and
the other is being considered for removal (rust-lang#17333)
Fixes rust-lang#17009
rust-rfcbot
added
final-comment-period
Collaborator
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
weihanglo
approved these changes
Aug 13, 2026
Member
There was a problem hiding this comment.
I am going to merge this and skip the 10 days FCP.
Reason being: Unlike build-plan, which we spent effort on communicating the removal. The --breaking flag has well-known, battle-tested alternatives like cargo upgrade from cargo-edit, and dependabot/renovate for CI auto upgrades. Users have the migration paths.
Sorry for the inconvenience if your workflow already adopted this, and thanks for being testers for nightly features.
rustbot
removed
the
S-waiting-on-review
This was referenced Aug 13, 2026
epage
added a commit
to epage/cargo
that referenced
this pull request
Aug 13, 2026
To ensure dependencies have had a chance to be scanned, a user can set:
```toml
[registry]
global-min-publish-age = "7 days"
```
To force a critical update through, a user can
```console
$ CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update -p foo
```
That will be preserved within the lockfile.
To ensure users can observe what is going on and address concerns,
- Locking messages notify of:
- That min-publish-age is in use and what the age is if there is a
single one
- a newer, unpicked version is available and its age
- a version is being used that is incompatible with min-publish-age
(either through `allow` or an unchange dep shown through `-v`)
- Error messages notify of:
- a newer, unpicked version is available and its age
- a compatible version requirement to downgrade to
- how to use `CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE`
Items from the tracking issue:
- `deny` precedence between this and `incompatible-rust-version`: we can
always adjust this over time
- the `registry.min-publish-age` / `registries.*.min-publish-age` precedence rule: mimics credential providers
- `cargo install` behavior
- there was some confusion over what was being stabilized due to edits
that happened during the FCP that weren't noticed
- `resolver` is defined as not affecting `cargo install` which this
preserves, just like `incompatible-rust-version`
- `cargo update --breaking`: this feature is being stabilized first and
the other is being considered for removal (rust-lang#17333)
Fixes rust-lang#17009
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR try to resolve?
Tor did a lot of great work on this within the constraints they had. The problem is what they uncovered through development: challenges with the current model for
updateand what I at least see as the ideal model forupdate --breaking(#14259).I think we need to more closely examine the semantics of
cargo updateto understand what we want out of both.I also think seeing
uv lockopens up new design possibilities that give us some more flexibility. We don't have to restrict ourselves to the interface ofcargo updatebut can deprecatecargo updatein favor of acargo lock upgradeand add acargo upgradecommand.This is in enough of a half-working state, that I think its fine to push people back to
cargo upgradethat are using it.The tracking issue is fairly quiet.
By removing this, we also simplify discussion of expectations of other features that overlap, like min-publish-age.
Technically, support in
--breakingfor min-publish-age wouldn't block min-publish-age but it represents one more thing we need to track and do to get it ready for stabilization.Closes #14259
Closes #14140
How to test and review this PR?
The references to this that I did find are:
Followup: #12425 needs to be updated to reflect this