RFC: Set a minimum Rust policy

[cuviper]

Set a formal policy for the minimum supported Rust version in rayon and rayon-core.

• We will support at least one year of Rust compilers, meaning that our chosen minimum will be at least one year old at the time we release any rayon crate requiring that.

• Increases to our minimum supported Rust will also require a new minor release in the semantic version of rayon crates, not just a patch release.

(rendered)

[nikomatsakis]

I am pretty happy with this overall plan.

[nikomatsakis]

I've not thought at all about how the "1 year" threshold corresponds to distro release schedules and the like. Is there possibly a choice (18 months?) that will work better for some reason or another?

[cuviper]

I think there's no clear choice, but one corroborating factor is that Firefox ESR rebases about once a year, requiring a new Rust toolchain. So even conservative enterprise distros have a strong motivation to update for that, and hopefully that's available to their users too.

FWIW, for RHEL we announced quarterly Rust updates. There's some added release pipeline delay, so at the worst (right before a new update) it will be a little more than a quarter behind. Then I figure some slop time is needed for customers to actually update.

[ghost]

This looks great to me!

Just something to have in mind: I'm considering bumping the requirement for Crossbeam to 1.34 eventually (lots of good stuff in that release, like stabilized AtomicU64). Later on will come MaybeUninit, which is also pretty useful for us, so we'll want to bump the version again.

All that said, I'll try to delay those bumps as much as possible. And when we do bump the minimum Rust version in Crossbeam, I'm pretty sure we'll still be able to support older Rust versions behind a feature flag so that Rayon doesn't suffer.

(Right now Rayon is stuck with a really old Rust version, supporting which is not as easy.)

[ghost]

Also, just a side note on how Tokio deals with this problem.

Tokio's policy is: minimum required Rust version <= two versions behind the latest stable one.
For example, the current stable version is 1.34 so Tokio supports 1.32.

[cuviper]

@stjepang

I'm considering bumping the requirement for Crossbeam to 1.34 eventually [...] All that said, I'll try to delay those bumps as much as possible.

Much appreciated!

And when we do bump the minimum Rust version in Crossbeam, I'm pretty sure we'll still be able to support older Rust versions behind a feature flag so that Rayon doesn't suffer.

Consider doing this behind the scenes in the build script if possible, using something like autocfg. I intend to transition Rayon's build script to that too, as it's meant to centralize the way to do feature probing. This way the new stuff Just Works when the rustc or std features are available.

Tokio's policy is: minimum required Rust version <= two versions behind the latest stable one.
For example, the current stable version is 1.34 so Tokio supports 1.32.

IMO that's too fast for distro toolchains to keep up, but it's also hard to say whether such users really need to be able to use current Tokio too. For existing code, they can stay on older versions of the crate, but I think for new users it would be frustrating to figure out compatibility.

For example, a while ago I wrote a post on getting started with rust-toolset in RHEL7, which included a Rayon example. It would be really sad to me if that became unusable after only 12 weeks (2 Rust releases), just because Rayon had moved on while the distro packages hadn't had a chance to update yet. Of course we'll require something newer eventually, hence this RFC, but give enterprise a chance to keep up! 🙂

[ghost]

Consider doing this behind the scenes in the build script if possible, using something like autocfg.

Oooh, that looks sweet! Thanks for the suggestion :)

For example, a while ago I wrote a post on getting started with rust-toolset in RHEL7, which included a Rayon example. It would be really sad to me if that became unusable after only 12 weeks (2 Rust releases), just because Rayon had moved on while the distro packages hadn't had a chance to update yet. Of course we'll require something newer eventually, hence this RFC, but give enterprise a chance to keep up! slightly_smiling_face

Totally makes sense and sounds like a good plan to me! 👍

[nikomatsakis]

We decided to accept the RFC! Huzzah!