MSRV policy?

[overlookmotel]

What is our policy on MSRV?

A while back it was latest 6 minor versions.

At some point we contracted that to 5 minor versions - I'm not sure when, or what motivated that.

More recently, I bumped MSRV to 1.81.0 in #8931 because we discovered that various crates would not compile on the advertised MSRV 1.80.0. But that was only intended to be a temporary thing - I didn't intend to permanently alter the policy to be that we only support latest 4 minor versions.

#9270 today bumped MSRV to 1.82.0, continuing the 4-month rule.

Opening this issue to clarify what our policy is?

Personally I thought that 6 was a decent number - giving consumers 6 months to update their Rust version. But if we think 6 is overly generous, perhaps we should contract it to 3 (quarter year) and then stick with that?

[Boshen]

Saw this: time-rs/time#535

It's a balance between us (core contributors) enjoying the latest version of rustc, while waiting for dependents to catch up.

At present, our only major dependents are Rolldown and nova, where I actively test oxc against.

There are currently no other major project approach us for a MSRV policy.

So given the above context, let's try and make it N-3 or even N-2 after the next release.

The next next release will be upgraded to Rust edition 2024.

[Boshen]

I'll keep this issue open until I document the reasoning in Cargo.toml after the next release.

[overlookmotel]

Saw this: time-rs/time#535

Interesting. Lots of people demanding long MSRVs in that thread.

However, we're in a rather different situation from time crate, as you say. We're not a widely depended-on "core" crate, and we're still moving fast and regularly making breaking changes anyway.

N-3 seems like a decent plan to me. We could go to N-2, but I wonder if we gain much from that 1 extra month. With the exception of const {} blocks, there hasn't been any feature I can remember that was an actual blocker to making something possible while waiting for it to come within our MSRV. Usually new stabilized APIs are essentially syntax sugar. But if you want to go N-2, I won't fight you!