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

Extending accepted metadata is a potential backcompat hazard #3291

Closed
Ryman opened this issue Nov 14, 2016 · 2 comments
Closed

Extending accepted metadata is a potential backcompat hazard #3291

Ryman opened this issue Nov 14, 2016 · 2 comments

Comments

@Ryman
Copy link

Ryman commented Nov 14, 2016

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.

@alexcrichton
Copy link
Member

Yeah unfortunately there's not really anything we can do here. All the relevant bugs have been fixed, so...

@carols10cents
Copy link
Member

Closing this issue because I think solving the root cause is best addressed by RFCs like these:

None of these have been accepted, but I know there are people working on the successors to these RFCs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants