Minimum Rust version policy

[ishitatsuyuki]

Throughout the codebase there are extensive use of old syntax that were superseded by new features like match ergonomics, inclusive ranges, and struct field names sugar.

What's our policy on minimum Rust compiler version? I guess we can just opt for bumping it in next major (0.x) release.

[mitchmindtree]

I'm not aware of any existing policy, but it would be nice to establish one!

Perhaps first it would be worth identifying the current minimum required version (not sure how to best go about this)? Then we could take a look at the plans for upcoming work (e.g. #268, #204) and identify any more modern-rust features we might need? I guess it's reasonable enough to raise the minimum to some more recent version if there's a motivating factor in the code-base and it happens between major version bumps?

[Lokathor]

Hi, I've been going around trying to get folks to have such a policy and so I'm happy to find this issue.

It seems that currently appveyor is still using stable and so is travis. The first step to finding a current minimum version would be to just edit the word stable to be a particular full version number, such as 1.36.0 and let CI run again. You can "binary search" the version up and down until CI breaks on one version and works on the next, then you know.

[est31]

Through trial and error I've determined that current master needs at least Rust 1.32.0. Rust 1.31.0 doesn't work because there, macro_literal_matcher isn't stable yet. This is incurred by code in the crate itself as well as dependencies.

Note that taking this version and fixing it forever is not doable without additional steps like commiting Cargo.lock into git like the failure crate does, because one of the recursive deps of cpal has a 2-releases-back MSRV policy: rust-lang/backtrace-rs#211 (comment)

We can also think about turning off optional features of the failure crate. Then we'd have less deps and would avoid the backtrace crate.

[joseluis]

Acording to cargo-msrv the MSRV as of today is 1.60.0.

[roderickvd]

MSRV is 1.70 but the question is if we have a policy. We don't but I think it'd be good to have one. Given cpals rather low-level and ubiquitous nature, I think it should be fairly conservative. Open to proposals.

[Lokathor]

I was convinced recently, for wide and safe_arch, to set rust-version in the Cargo.toml, and to only bump the rust-version in minor crate version bumps so that patches can always be back ported to an old crate version and rust version.

[roderickvd]

Yes, for sure MSRV bumps should lead to a minor version update. Question is: under which circumstances would we allow upgrading from current 1.70 MSRV to another one? How many Rust versions should we support, and for how long?

[Lokathor]

Update literally whenever you need it, just use a CI run against a specific version to keep track of it.

The point of the new resolver that the ecosystem is moving to is that people don't get newer code than their toolchain can handle, so that libs don't have to worry about avoiding updates every single moment of the day.

[est31]

It's not as simple, as often times updates contain stuff like security fixes, new features, bug fixes, etc, or just compatibility fixes (forward compatibility to newer compiler version). People on older compilers might still want them. For core libraries like cpal, I recommend supporting semver at least 1 year into the past. So 1.70 is a fine requirement.

[roderickvd]

People on older compilers might still want them. For core libraries like cpal, I recommend supporting semver at least 1 year into the past.

Couldn't agree more. As well as:

It's not as simple

😄 because when I started switching the CI from Rust stable to 1.70 as MSRV initially in #1076, reality hit that:

• none of the hosts actually compiled on 1.70
• the MSRV actually depends per host/platform

Plowing through it to find the MSRV per host, and downgrading dependencies where it doesn't hurt, we got to these:

MSRV_AAUDIO: "1.82"
MSRV_ALSA: "1.77"
MSRV_COREAUDIO: "1.80"
MSRV_JACK: "1.80"
MSRV_WASIP1: "1.78"
MSRV_WASM: "1.82"
MSRV_WINDOWS: "1.82"

...and I set overall rust_version to 1.77 because of it.

So I propose to close this with the policy decision: as low as reasonably possible, preferably 1+ year, yet as high as we must. Fortunately the highest MSRV - 1.82 - is also from over a year ago: Oct. 17, 2024.