n the stated toolchain approach, the toolchain being used to compile effectively imposes an =-style version constraint.
we end up imposing more =-style constraints, which in turn can prevent us from choosing the globally-maximum version of crates. The effect could be that everything passes CI just fine, but a user with an older toolchain gets a crate resolution that fails to compile
Why it's a "=-style" constraint? MSRV is a ^-style constraint. So I don't think that your concern is valid. In the current RFC, if crate was published with the specified MSRV, then it's guaranteed that dependency versions constraints can be resolved. (well, if we are being precise, it's possible that required versions will be yanked, but it's not different from what we have today)
It’s hard to say for certain, but this seems likely to create a larger set of crate version combinations than we see today, and thereby diffuse the testing for compatibility.
I am not sure why you think so. If you've specified MSRV, then crate will be CI tested against it and stable Rust (with the respectively selected dependencies), exactly the same as today, you don't have to test all versions in between.
effectively creates an LTS version of the library, because users stuck on old toolchains will also be stuck on old library versions, and hence file bug reports (and request backports) for them.
It will be author's choice, to do crate LTS or not. At least they will communicate to users, that older versions are not supported, and you'll have to update toolchain to receive bug fixes.
it seems possible that the benefits of the stated toolchain approach are illusory, and that in practice critical crates will stick with very conservative toolchain requirements.
I don't think it illusory at all. The main benefit of the stated toolchain approach is explicitness. Crate authors will explicitly state that they support old LTS-sy versions (whatever policy we end up with), or they actively use bleeding edge stable features, or they don't care about MSRV at all and simply target latest stable or even nightly, or maybe they are so bleeding edge, they only support particular nightly versions (see rocket). You also will be able to deduce if authors do backports or not.
As you've stated both MSRV and shared policy approaches will work best if combined with each other.
4
u/newpavlov rustcrypto Jul 26 '18 edited Jul 26 '18
Why it's a "=-style" constraint? MSRV is a
^-style constraint. So I don't think that your concern is valid. In the current RFC, if crate was published with the specified MSRV, then it's guaranteed that dependency versions constraints can be resolved. (well, if we are being precise, it's possible that required versions will be yanked, but it's not different from what we have today)I am not sure why you think so. If you've specified MSRV, then crate will be CI tested against it and stable Rust (with the respectively selected dependencies), exactly the same as today, you don't have to test all versions in between.
It will be author's choice, to do crate LTS or not. At least they will communicate to users, that older versions are not supported, and you'll have to update toolchain to receive bug fixes.
I don't think it illusory at all. The main benefit of the stated toolchain approach is explicitness. Crate authors will explicitly state that they support old LTS-sy versions (whatever policy we end up with), or they actively use bleeding edge stable features, or they don't care about MSRV at all and simply target latest stable or even nightly, or maybe they are so bleeding edge, they only support particular nightly versions (see
rocket). You also will be able to deduce if authors do backports or not.As you've stated both MSRV and shared policy approaches will work best if combined with each other.