Stability of cargo metadata output

[Person-93]

Problem

The output of cargo metadata --format-version=1 is a bit different in beta. For optional dependency foo, it adds "foo" = ["dep:foo"] to the feature list. This breaks one of my crates that reads the output it.

Steps

Run cargo +beta metadata --fomat-version=1 in any workspace with optional dependencies.

Possible Solution(s)

Define and document a policy for what type of changes are allowed in the output without requiring a bump to the format version argument.

Notes

The crate in question is a CI tool for running a cargo command repeatedly with all valid sets of features. It reads the metadata so that it doesn't run the two extra times for features that are dependencies of other features. As of now, it makes its list of feature sets by reading the features field to get the list of features and their dependencies, and the dependencies field to get the list of optional dependencies.
With the beta version, are all optional dependencies guaranteed to show up in the feature list?

Version

cargo 1.60.0-beta.1 (ea2a21c 2022-02-15)
release: 1.60.0-beta.1
commit-hash: ea2a21c994ca1e4d4c49412827b3cf4dcb158b1d
commit-date: 2022-02-15
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1m)
os: Debian 11 (bullseye) [64-bit]

[ehuss]

It definitely would be great to clarify the documentation for how things can change. In general, new versions may introduce new fields. The change in value formats is a little more nebulous, so it might be difficult to specify exactly what can and can't change. The types of the values won't change (like for example, a string won't change to an array), but the contents might (for example, if cargo ever adds a new dependency kind, then the "kind" could add a new value).

[Person-93]

I think the important thing is that the values can be used the same way, although that might be a bit nebulous as well.
My crate reads the features from the manifest and then compiles and runs the tests with different combinations of features. The problems is that the new dependencies can't be passed to cargo as part of the feature list.

[weihanglo]

#12313 is an effort of this, and for external tool maintainers we occasionally post announcement that may potentially break tools on Zulip t-cargo/build-integration. Please subscribe if you're interested.

#12377 is also relevant however regarding --message-format=json.

Close as resolved via #12313. Thank you!