RFC: Precise Pre-release cargo update
#3493
Conversation
This RFC proposes extending `cargo update` to allow updates to pre-release versions when requested with `--precise`. For example, a `cargo` user would be able to call `cargo update -p dep --precise 0.1.1-pre0` as long as the version of `dep` requested by their project and its dependencies are semver compatible with `0.1.1`. This effectively splits the notion of compatibility in `cargo`. A pre-release version may be considered compatible when the version is explicitly requested with `--precise`. Cargo will not automatically select that version via a basic `cargo update`.
ehuss
added
the
T-cargo
| [drawbacks]: #drawbacks | ||
|
|
||
| - Pre-release versions are not easily auditable when they are only specified in the lock file. | ||
| A change that makes use of a pre-release version may not be noticed during code review as reviewers don't always check for changes in the lock file. |
There was a problem hiding this comment.
Possible mitigation: emit a warning when a pre-release version is locked and the version requirement doesn't use pre-release components. Assuming we get some way to do --deny=warnings for cargo-warnings in CI, that would require adding an allow somewhere outside the lockfile so that it's more reviewable.
There was a problem hiding this comment.
(I was gonna say this fits in well with warnings for yanked crates too, but the warning I always thought existed when you have a yanked crate as a dependency doesn't actually exist 😓)
|
@rfcbot fcp merge Internally, this treats pre-release like yanked, which is a strong foundation for us to build on. This also aligns with other decisions (breaking changes, yanked) for "trusting the user" when it comes to |
|
Team member @epage 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. |
rfcbot
added
proposed-final-comment-period
Co-authored-by: Eric Huss <[email protected]>
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
Thanks for the heads up. This looks great to me. |
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
|
Huzzah! The @rust-lang/cargo team has decided to accept this RFC. To track further discussion, subscribe to the tracking issue here: |
Rendered
FCP
Tracking Issue
This RFC proposes extending
cargo updateto allow updates to pre-release versions when requested with--precise. For example, acargouser would be able to callcargo update -p dep --precise 0.1.1-pre.0as long as the version ofdeprequested by their project and its dependencies are semver compatible with0.1.1. This effectively splits the notion of compatibility incargo. A pre-release version may be considered compatible when the version is explicitly requested with--precise. Cargo will not automatically select that version via a basiccargo update.Original Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Semver.20compatible.20pre-release.20versions.20.28maybe.20pre-RFC.29