-
Notifications
You must be signed in to change notification settings - Fork 185
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
What versions do platform support track? #371
Comments
I think it would be ok to drop now-unsupoorted OS versions in a non-major release (i.e. this would not be a breaking change). @newpavlov any thoughts here? It might be nice to have an official policy which we mention in the README. |
We have the precedent of removing Windows XP support in v0.2.1, which has followed the removal in |
Great, that makes things pretty easy then. Agree that the minor version increases in the future would be a polite allowance to downstream users. Since both of you agree on the policy, does this plan seem fine?
|
@BlackHoleFox that sounds perfect! Thanks for taking care of this. I also don't think it's necessary to wait until 1.74 comes out to submit/merge the PR. We just need to be sure to not cut a release of getrandom until 1.74 is released. |
Hiyo. I was poking around random generation for Apple platforms and while tweaking Miri realized
getrandom
attempts todlsym
thegetentropy
function. The reasoning has been pretty simple for a while: Old macOS didn't have it. But once Rust 1.74 comes out that won't follow since upstream has now dropped pre 10.12. I'm working on cleaning up things in std as a result.Similarly, the Android and Linux implementations are also following this as even with their semi-recent bumps, the
getrandom
syscall isn't yet guaranteed to be present.So that nicely swings around to the question: What is
getrandom
's policy for platform version assumptions? Does it just follow what the lateststd
does (as this comment sort of implies)? Or does the 1.36 MSRV implygetrandom
can't make newer platform assumptions and is stuck supporting versions of OSes that are long deprecated?libc
seems to have taken the path of not supporting the removed versions via changes such as rust-lang/libc#3362.The text was updated successfully, but these errors were encountered: