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

Minimum supported Rust version - policy #1076

Closed
davidhewitt opened this issue Aug 2, 2020 · 3 comments · Fixed by #1086
Closed

Minimum supported Rust version - policy #1076

davidhewitt opened this issue Aug 2, 2020 · 3 comments · Fixed by #1086

Comments

@davidhewitt
Copy link
Member

Following on from #1069, where we decided not to update MSRV right now, I just wanted to post a discussion over what we do want to support for MSRV.

Discussion in #1069 suggested we support at least the current version of RHEL, and maybe also Debian.

TLDR: I think we should continue to aim to always support at least RHEL, but don't think it's worth looking all the way back to Debian's version of rustc.

RHEL

RHEL updates rustc every three months; this is equivalent to every odd-numbered compiler version. https://access.redhat.com/documentation/en-us/red_hat_developer_tools/1/

Currently supports 1.43.

Debian

I also took a look at what Debian requires. It looks like their rustc does not receive version updates so frequently; their current version is 1.34. https://packages.debian.org/buster/rust/rustc

The next Debian version looks like it will support 1.43. https://packages.debian.org/bullseye/rust/rustc

So we already don't support current Debian, but if we keep MSRV back for a while, eventually we will.

Proposal

First I should clarify that we shouldn't update rustc without reason. Eventually, new dependencies or language features will create desire to update.

When we bump MSRV in a pyo3 update, here's three rough policies we could follow:

  1. Don't care about the rest of the ecosytem. We could just bump MSRV as high as we want whenever it suits us, but I think that this risks annoying quite a number of users if we're always demanding the latest rustc.
  2. Try to keep some level of backwards compatibility. If we take latest RHEL as an example, supporting this would mean we're ~3 months or so behind latest rustc. I think this allows us to get new features when we need them, while also giving users time to upgrade.
  3. Support a wide ecosystem. Debian's rustc is already over a year old, and looks like it will probably be about 2.5 years old by the time the next Debian version is released. Supporting Debian would probably support almost all Rust users, but we would be very constrained with regards to updating PyO3 to leverage new language features and packages.

Overall, it seems to me like (2) is a good compromise.

@programmerjake
Copy link
Contributor

Agreed. Nearly anyone doing serious Rust dev will have a recent version of rustc.

@birkenfeld
Copy link
Member

Well, as a developer, of course. When I deploy stuff, I try using the toolchains available on those systems.

But for now I agree with (2), as long as Rust's iteration cycle and pace of development is still pretty high it makes sense not to drag too much.

@davidhewitt davidhewitt linked a pull request Aug 6, 2020 that will close this issue
@davidhewitt
Copy link
Member Author

Thanks for the feedback; I've briefly mentioned this in the new contributing notes I drafted this afternoon.

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