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

Cargo versioning #2182

Closed
wants to merge 1 commit into from

Conversation

@joshtriplett
Copy link
Member

commented Oct 19, 2017

Rendered

RFC co-authored by myself and @wycats, and pre-reviewed by @alexcrichton.

@withoutboats

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2017

To summarize the RFC as I understand it: the idea is that cargo can figure out your minimum version requirements based on what features of cargo are necessary to compile it, and that it will then record it in the index entry for your crate. This will then influence error messages and version resolution. The user interface doesn't need to change to support this (that is, you don't specify a minimum version in your Cargo.toml).

Is that right?

@bryteise

This comment has been minimized.

Copy link

commented Oct 19, 2017

Would it be possible to allow an optional cargo version number if crate authors want to be able to enforce they will be using other newer features of cargo but currently do not?

@joshtriplett

This comment has been minimized.

Copy link
Member Author

commented Oct 19, 2017

@withoutboats Correct. This is best-effort, and if the schemas turn out to be incorrect we can fix bugs in them.

@bryteise Perhaps, though the default Cargo.toml should not include a version number. But I think the reverse seems more important: "don't let me use any features from Cargo newer than this". Again, best-effort, but useful as a local development complement to a good CI system.

@Ericson2314

This comment has been minimized.

Copy link
Contributor

commented Feb 5, 2018

Sorry to take so long to get to this. This is generally quite good, but I am also a bit wary of no manual recourse in Cargo.toml files themselves. In particular, the tentative ideas about non-registry dependencies:

For crates obtained via alternate registries or directly from version control or filesystem paths, Cargo may attempt to use the schema provided by crates.io-index to parse the Cargo.toml file and distinguish types of errors, but may have to continue and warn rather than stopping with an error.

seem sub-par. crates.io access for non-crates.io deps seems likely to cause confusion, non-determinism, and annoyance when there is no internet access. An optional schema version in Cargo.toml circumnavigates the any need for such heuristics.

@Ericson2314

This comment has been minimized.

Copy link
Contributor

commented Feb 5, 2018

N.B. haskell/cabal#4899 is the plan for schema versions for Cabal. Their situation is more awkward because Cabal files are a non-standard syntax, in addition to schema within that syntax, but I'd thought i'd still link for reference.

@joshtriplett

This comment has been minimized.

Copy link
Member Author

commented Sep 18, 2019

@rfcbot postpone

I no longer think this is the right approach. I think we need to have a new index format that incorporates a Cargo version number, but I don't think we should have a complex detection mechanism like this.

@rfcbot

This comment has been minimized.

Copy link

commented Sep 18, 2019

Team member @joshtriplett has proposed to postpone 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.

@Eh2406

This comment has been minimized.

Copy link

commented Sep 18, 2019

Note that the MSRV RFC is not so different from the first alternative.
@rfcbot reviewed

@ehuss

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2019

@rfcbot reviewed

@rfcbot

This comment has been minimized.

Copy link

commented Sep 18, 2019

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

@rfcbot

This comment has been minimized.

Copy link

commented Sep 28, 2019

The final comment period, with a disposition to postpone, 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.

The RFC is now postponed.

@rfcbot rfcbot closed this Sep 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.