You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every time a new release of rand happens, it would make sense to migrate rust-lang/rust to use it, since it is a huge user of rand that can discover oversights and design directions that might be problematic.
It is a particularly good place to test "future compatibility"-shims. These are hard to write, but the dependency graph of rustc is big enough to exercise them in many different ways.
I disagree about it being a good place to test compatibility shims — small examples are quite enough. The issue with rand 0.6.5 is simply that it violates semver rules as you pointed out — I don't believe this is worth fixing now, since doing so would require yanking crate versions already in widespread usage, downgrading to rand_core 0.3.x and would break no_std support for all Rand 0.6.x users (unless we instead pushed a breaking change to rand_core 0.3.x and hoped that caused less damage). Of course, we will try our best not to this again in the future 😉
As for upgrading rustc, I don't have the time myself this week and perhaps also not in the near future. Whoever gets there first I guess.
I am just pointing out that probably nobody is going to try because it is currently already too much work, and this will mean that 0.6.1 and 0.7, newer 0.7.x versions, and in the future 0.8, 0.9, etc. will need to build and work properly in rust-lang/rust dependency graph. The more versions get released the more work it is to update, the harder it is going to be to find a workaround to fix things quickly if things break, etc.
Activity
dhardy commentedon Jul 31, 2019
I disagree about it being a good place to test compatibility shims — small examples are quite enough. The issue with rand 0.6.5 is simply that it violates semver rules as you pointed out — I don't believe this is worth fixing now, since doing so would require yanking crate versions already in widespread usage, downgrading to
rand_core0.3.x and would breakno_stdsupport for all Rand 0.6.x users (unless we instead pushed a breaking change torand_core0.3.x and hoped that caused less damage). Of course, we will try our best not to this again in the future 😉Edit: of course, #852 is still unexplained.
As for upgrading rustc, I don't have the time myself this week and perhaps also not in the near future. Whoever gets there first I guess.
gnzlbg commentedon Jul 31, 2019
I am just pointing out that probably nobody is going to try because it is currently already too much work, and this will mean that 0.6.1 and 0.7, newer 0.7.x versions, and in the future 0.8, 0.9, etc. will need to build and work properly in rust-lang/rust dependency graph. The more versions get released the more work it is to update, the harder it is going to be to find a workaround to fix things quickly if things break, etc.
mati865 commentedon Aug 2, 2019
I'll see what I can do about this issue.
mati865 commentedon Aug 5, 2019
Upgrading all Rust crates to
rand 0.7fail with the same error as upgrading torand 0.6.5#852dhardy commentedon Aug 28, 2019
Thanks @mati865 for addressing this.