rfcs (original) (raw)

@mitsuhiko With the terminology change, the only remaining issue is the sentence: "Effectively the idea is that if your own library bumps a public dependency it means that it's a breaking change of your own crate."

I realize now this sentence is doesn't actually effect what this RFC specifies, so as far as the detailed design goes we're all good---feel free to just cut that sentance and ignore the rest of this post :).

But for the record, actually a changing of a dep should never be a breaking change. In the private dep case, downstream cannot tell at all, so we're good. In the public dep case, the solver will simply not use the new crate if the public dep cannot be unified with other public deps.

I wrote before

This is an instance of the general principle that the version of a crate is like a fallback / catchall that describes the remnants of the interface not already accounted for in the crate metadata, and constrainable with a dependency.

I think I have a better way of describing things. The general maxim for compat is "if I publish this crate, in all solutions where this this crate could be substituted for another, things must work in both case". If there is a solution where the substitution breaks, we could try to fix that case, or we could try to rule it out.

Since public deps may be exposed but also must exist once, any bounds adjustment is OK because the version unification would rule out laxer bounds switching to another version the other crates in the plan cannot cope with.

Mathematically, one can view a crate wrt compatability as Map<PubDeps, Map<Name, Item> (maps are partial functions). Just as adding definitions to a crate preserves compatibility, so relaxing bounds does too---both just extend domains of the partial functions. Whereas removing definitions does not preserves compatibility, tightening bounds is fine because solver-time failures are fine (the solver just moves on) whereas build-time errors aren't.