Skip to content
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

Closed
BlackHoleFox opened this issue Oct 1, 2023 · 4 comments · Fixed by #387
Closed

What versions do platform support track? #371

BlackHoleFox opened this issue Oct 1, 2023 · 4 comments · Fixed by #387

Comments

@BlackHoleFox
Copy link
Contributor

BlackHoleFox commented Oct 1, 2023

Hiyo. I was poking around random generation for Apple platforms and while tweaking Miri realized getrandom attempts to dlsym the getentropy 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 latest std does (as this comment sort of implies)? Or does the 1.36 MSRV imply getrandom 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.

@josephlr
Copy link
Member

josephlr commented Oct 1, 2023

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.

@newpavlov
Copy link
Member

We have the precedent of removing Windows XP support in v0.2.1, which has followed the removal in std. So I think it's a reasonable policy to follow std and allow removal of target support in non-major releases. Post-1.0 we probably should do it in minor releases, but before that we have no choice but to do it in patch releases.

@BlackHoleFox
Copy link
Contributor Author

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?

  • Wait for Rust 1.74 to come out and abandon older Apple OSes.
  • I make two PRs:
    • Mirror the in-progress stdlib changes (which will probably be merged by then) for Apple's RNG logic here to match
    • Formally document the policy in the README

@josephlr
Copy link
Member

josephlr commented Oct 6, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants