Cargo versioning

[joshtriplett]

Rendered

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

[withoutboats]

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]

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]

@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]

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]

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]

@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]

Team member @joshtriplett has proposed to postpone this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @alexcrichton
• @ehuss
• @joshtriplett
• @nrc
• @withoutboats

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]

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

[ehuss]

@rfcbot reviewed

[rfcbot]

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

[rfcbot]

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.

[joshtriplett]

One further followup on this: Since Cargo 1.19, in mid-2017, Cargo now ignores index entries it doesn't understand.