RFC: Cargo feature descriptions by tgross35 · Pull Request #3485 · rust-lang/rfcs (original) (raw)
The most elegant schema would be to mirror these tables directly into metadata.
That is, update:
<simple form>To be something like:
<detailed form>However; being that Cargo needs to support all possible schema versions forever (as I understand it), it seems like the barrier for a breaking schema change is quite high.
As these details seem to be implicit, you are saying this would be a new --format-version <VERSION>?
Yes, 'wed need to support generating data for all possible schemas for ever.
Pulled in your ideas and added some more. Mind adding this to the RFC alternatives and documenting which you think we should go with and why? We can then discuss it in a cargo team meeting.
A new message format version
We either deprecate the current version, making new features all-or-nothing, or need to add features to both versions
As the format-version is defaulted (with a warning), we'd need to consider what the migration path would be to v2.
A parallel table for just this
This is your features_metadata.
We need to do this for every new field. While #3663 was closed, doing something like that would put coupled data in parallel tables.
A new features2 or features-detailed
Automatically gets new data.
Seems inelegant but that isn't necessarily a blocker.
Use simple form where possible
Technically, this gets us into the territory of "forwards compatibility" rather than "backwards compatibility", ie things break when new features are used with old tools rather than breaking existing features on new tools.
We'd need to make sure we render in the "simple" format whenever we can.
This can still be disruptive to the ecosystem. serde handles adding of new fields well (ignore) but not changing of data types (error). Most people go through cargo_metadata so we'd likely only need to implement things once and then people just need to update.