Is the recent MSRV bump actually required?

[alerque]

In 2230202 the MSRV was bumped to something pretty aggressive, especially for project that are distributed by Linux distros and need to be buildable with the current packaged toolchain.

Is it necessary to bump the MSRV for this? Would there be a way to gate this such that the change is only made conditionally on having a toolchain that supports it?

If it's not feasible of course I can just hold back the dependency for now, just asking for clarification.

[cesarb]

I incorrectly believed that the new Rust-version aware resolver would make users of older Rust compilers automatically use the 0.4.2 version of this crate instead of the newer 0.4.3. Unfortunately, it seems this only happens when the final project is using Rust edition 2024 (or opts in to the newer dependency resolver).

I followed the suggestion given at #13 and yanked the 0.4.3 release (releasing 0.5.0 instead), so this shouldn't be a breaking change anymore. You can stay on 0.4.x until your own MSRV is higher than 1.95.x.

The ideal solution would probably be something like the classic autoconf approach, which does a trial compile to see if the current compiler has the necessary support. But that would require adding a build.rs to this crate, and would also be more fragile (risk of falsely detecting a lack of support due to unrelated compiler errors; this happened recently to a lot of autoconf-using projects since an unrelated change to the C compiler made it reject the tests due to them using obsolete implicit declarations).

[alerque]

Yes, old projects can use the new resolver even with an old edition of Rust, but they do have to add a Cargo config to get it, which many/most don't seem to be aware is possible or how much trouble it saves them using the MSRV aware resolution!

It's true that you could test for support in a build.rs, and also true that brings some complexity even if it can be pretty robust.

Another approach is to add feature flags for things only supported in new toolchains. The flags can be part of the default set, but that would give consumers a pathway to not use default features and then only enable the flags up to the versions they could support. Quite a few projects do this although it certainly isn't universal and doesn't help the resolver auto detect what it can update. Off the top of my head snafu is one to look at, see the rust_1_81 config option in the manifest. The feature itself does nothing, it just gives you something to gate on and conditionally enable features in the code.

Given there doesn't seem to be any other compelling reason to update at all that may not be necessary here since folks can stay on 0.4, but if you did add new features in a future release that people wanted to take advantage of without the more niche platform support in 0.5 that would be a way you could open up access to new versions without people getting blocked on the MSRV.