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
|
@eopb I hope its ok that I went ahead and directly applied my feedback. My intention was to clarify and fill in holes and not to change the meaning of your RFC. Don't feel obligated to changes that I made. |
| [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
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