Repository navigation
trait impl disappeared without bumping major version #94
Description
Sorry to be the bearer of versioning news, 0.1.10 contains a backwards-incompatible change with respect to 0.1.8 and so on - the feature flags around error_impls changed, and had been accidentally(?) including error_impls for specific OSes regardless of std being selected or not.
The change around feature flags makes sense, but without bumping major versions, version 0.1.10 can cause breakages: see the end of the log here. The missing impl is because minisign depends on getrandom = "0.1.3", where 0.1.10 should be a backwards compatible update, but is not due to the missing trait. We can work around that by specifying std, but I wanted to make sure y'all knew about this.
Activity
newpavlov commentedon Aug 19, 2019
We could make
stdfeature enabled by default. Strictly speaking it also can be viewed as a breaking change forno_stdtargets (especially considering thatrand_coredoes not usedefault-features = "false"forgetranomright now), but since no one has complained about aboutcompile_error!on them, I guess it can be considered a lesser evil in this unpleasant situation.josephlr commentedon Aug 19, 2019
@newpavlov I agree, we should enable the
stdfeature by default to fix this issue and haverand_corepassdefault-features = falseso thatrand_corekeeps working onno_stdtargets (really, we should do that regardless). EDIT: we should also make suredefault-features = falseis passed for thelibstdpatch as well.We should prioritize not breaking
stdusers first and foremost.EDIT2:
It looks likeThis is wrong, see rust-random/rand#870randandrand_coreonly use getrandom iffstdis used, so they are OK. The only concern would berand_os, which would be broken by changing the defaults.dhardy commentedon Aug 23, 2019
I think the solution here is to yank 0.1.10 and prepare 0.2.0?
josephlr commentedon Aug 23, 2019
@dhardy I agree. My idea is as follows:
randto use it).