Extending accepted metadata is a potential backcompat hazard #3291
Description
I had a library dependency on serde_json 0.7 building on rustc 1.4.0 which used to build. It no longer builds as the registry information fails to parse with the error "the given version requirement is invalid".
Debugging this, it looks like the parser bails out when parsing the version number 0.8.0-rc1 (when parsing the summaries) which was published shortly after the successful build. Building continues to fail until rustc 1.8.0, and if I use the lockfile generated by the successful build then it still fails on 1.4-1.7 with the parse failure.
This is unfortunate as if one publishes a new crate version (e.g. a prerelease) which is accepted by a newer cargo, you run the risk of breaking all the builds depending on older versions of your crate & older rustc/cargo combinations.
I'm unsure if there's a fix here as my understanding of cargos interaction with the registry doesn't give us an opportunity for indirection to filter problematic information for older clients? Perhaps the best we can do is audit other points where we should try to be more liberal in what we accept (or ignore) in order to allow more forward compatability.
The issue is actually a bit more annoying in the linked library as the serde feature is intended to be optional, but the mention of serde_json or serde_codegen in the manifest even as optional non-active dependencies causes the build to fail.
Failure build log - probably incompatible with rust 1.4 since it bumps serde, but it has the same error so I can't actually determine what the legitimate minimum version is.
Related issue: #2751 - specifying the min-rustc/cargo version could help ensure that what we publish does indeed parse/build with the version we're trying to maintain compatability with.