Skip to content
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

RFC: Precise Pre-release cargo update #3493

Merged
merged 32 commits into from
Jan 13, 2024

Conversation

eopb
Copy link
Contributor

@eopb eopb commented Sep 20, 2023

Rendered
FCP
Tracking Issue

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-pre.0 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.

Original Zulip discussion: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Semver.20compatible.20pre-release.20versions.20.28maybe.20pre-RFC.29

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 ehuss added the T-cargo Relevant to the Cargo team, which will review and decide on the RFC. label Sep 20, 2023
@epage
Copy link
Contributor

epage commented Dec 12, 2023

@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.
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member

Choose a reason for hiding this comment

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

(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 😓)

@epage
Copy link
Contributor

epage commented Jan 3, 2024

@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 --precise.

@rfcbot
Copy link
Collaborator

rfcbot commented Jan 3, 2024

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 rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels Jan 3, 2024
Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

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

Just spelling nits.

text/3493-precise-pre-release-cargo-update.md Outdated Show resolved Hide resolved
text/3493-precise-pre-release-cargo-update.md Outdated Show resolved Hide resolved
text/3493-precise-pre-release-cargo-update.md Outdated Show resolved Hide resolved
text/3493-precise-pre-release-cargo-update.md Outdated Show resolved Hide resolved
text/3493-precise-pre-release-cargo-update.md Outdated Show resolved Hide resolved
text/3493-precise-pre-release-cargo-update.md Outdated Show resolved Hide resolved
Co-authored-by: Eric Huss <[email protected]>
@weihanglo
Copy link
Member

@rfcbot reviewed

Should we give maintainers of semver a head up of this?

@rfcbot rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Jan 3, 2024
@rfcbot
Copy link
Collaborator

rfcbot commented Jan 3, 2024

🔔 This is now entering its final comment period, as per the review above. 🔔

@epage
Copy link
Contributor

epage commented Jan 3, 2024

Should we give maintainers of semver a head up of this?

I made a passing reference but to be more explicit. @dtolnay this has impact on semver and we'd appreciate a look over.

@dtolnay
Copy link
Member

dtolnay commented Jan 3, 2024

Thanks for the heads up. This looks great to me.

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this RFC. to-announce and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Jan 13, 2024
@rfcbot
Copy link
Collaborator

rfcbot commented Jan 13, 2024

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.

@ehuss
Copy link
Contributor

ehuss commented Jan 13, 2024

Huzzah! The @rust-lang/cargo team has decided to accept this RFC.

To track further discussion, subscribe to the tracking issue here:
rust-lang/cargo#13290

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this RFC. T-cargo Relevant to the Cargo team, which will review and decide on the RFC. to-announce
Projects
Archived in project
Status: Unreviewed
Development

Successfully merging this pull request may close these issues.

8 participants