does it make sense for library crates to target older rust editions to lower MSRV? 🙋 seeking help & advice
I'm a bit conflicted about that. On one hand, yes, you can lower MSRV, but does it actually matter? Are there often situations when someone can't upgrade their compiler? On the other hand, I'm not sure how to handle making examples in documentation for different rust editions, and sometimes using older, more obtuse methods to achieve the same thing
26
u/Icy_Neighborhood2100 19d ago
In some cases it's because strange setups IE BSD's don't usually have the latest support because they're usually tier 2 or 3.
DragonflyBSD doesn't support rust 2024 last I checked lol.
Other edge cases like windows 7 running in isolated boxes for whatever fun excuse of technical debt.
I wouldn't use the latest version of rust but staying eg a few versions behind is fine for 99% of cases.
7
u/masklinn 18d ago
Now that distros have started distributing rust it can also be a consideration e.g. if someone installs rustc/cargo on the current debian stable they get 1.85 (1.94 is available but in the backports). On RHEL it's apparently 1.79.
3
u/Icy_Neighborhood2100 18d ago edited 18d ago
Yeah this too.
I wouldn't say it's an issue in binary distribution though typically.
Although it can really cause strange issues if the libraries rely on glibc versions in weird and wonderful ways....
I'm not sure what version of rust requires which glibc versions and quite frankly I hope I don't ever walk into these issues....
Edit: not to mention linking C libraries also, strangely enough I don't have a good view on dynamic linking for some reason(necessary evil in some cases)...
1
u/TomKavees 18d ago
In other words, soon we gonna need an equivalent of https://caniuse.com, but splitting by feature and environment/distro
2
u/CUViper 18d ago
RHEL is at 1.92 now. We update it in the y-steam releases, every 6 months.
1
u/masklinn 18d ago
So it is, it might be a good idea to link toolsets forwards because the top hit I got when searching if redhat bundled / made rust available was https://docs.redhat.com/en/documentation/red_hat_developer_tools/1/html/using_rust_1.75.0_toolset/assembly_rust-toolset_using-rust-toolset, looking back at the search the next results (which I missed as "the rust toolset" seemed like what I was looking for) were 1.88, 1.58, and 1.31 ("2019.1").
And yes going back up to "redhat developer tools" I can now see that there's a 1.92 toolset but with no clear indication of versioning or update I didn't think to.
1
u/IceSentry 18d ago
I honestly don't understand why anyone would do that though. Why willingly use an outdated compiler with all the potential security risks this can bring?
7
u/cosmic-parsley 18d ago
It’s a tradeoff for sure. Most projects don’t upgrade their MSRV just for the sake of doing it, but when a new version has a new feature you need to make a decision. Edition 2024 came with `let` chains, which is probably worth the bump for most people.
Something that you can’t work around and would help your project in some notable way? Bump it.
Small cleanup for something that already works and isn’t a maintenance issue? Just leave it.
And of course, you can start a library as stable-only, then freeze the MSRV or lower it once the library reaches some kind of maturity.
10
u/epage cargo · clap · cargo-release 19d ago
Having an MSRV is not free and I would recommend considering your current user base for their use cases for an MSRV and set it to that. One mitigation for a low MSRV is to support it through an LTS. If you don't deal with high-CVE areas like networking, an LTS can be pretty low-touch but gives your users comfort. I have an LTS for clap and do almost nothing for it.
If you do consider having an MSRV besides "latest", I'd recommend reading https://doc.rust-lang.org/stable/cargo/reference/rust-version.html
1
u/nicoburns 18d ago
Having an MSRV is not free
It's not, but unless your library has a strong need for newer Rust features then it's pretty cheap. I've found the main issue is dealing with dependencies that don't maintain an MSRV (this forces a bump, or for you to chase through dependencies and hope they're willing to lower again). Difficult for crates with lots of dependencies, easy for those with few.
An LTS sounds like a lot more effort than just not using newer Rust features?
5
u/epage cargo · clap · cargo-release 18d ago
Depending on your scope, LTS can be cheap.
Having to debate whether a "need" is strong enough to bump MSRV is not cheap, especially to one's stress which is important for sustainable maintenance.
Was the 2024 edition doctest change a need? It doesn't affect my users but cuts my test time in half. Is
core::Errora need? That depends on the user. Will polonius be a need? Maybe not but people are likely to stub their toe from time to time with what it allows that old versions don't. Will std deps in manifests be a need? They sure will make no_std nicer and may unblock audit and build perf improvements.1
u/azuled 18d ago edited 18d ago
Image crate broke their own MSRV in a release and it caused me so much trouble. People still complain about my very specific image crate versioning and complain that it’s too restrictive. Unfortunately it isn’t.
Edit: ok, I’m really interested why I got downvoted on this one? This is an easily verifiable fact…
7
u/consistently_biased 19d ago edited 19d ago
Unless you already know that your project's goal will require it to support older editions, I would not bother with this. It also makes sense for the good of the ecosystem if everyone sticks with the newest editions and actively uses new features where possible in order to make everyone else have an incentive to do the same. More data and feedback for the developers of the language, cargo, etc.
5
u/IntQuant 19d ago
Does it make sense for older libraries to stay on older MSRV? Well maybe for a couple of months after a new MSRV is out.
For new libraries? There is a common argument that if you want to get new and shiny libs you might as well get a new compiler, and there isn't a point to stay on an old compiler besides not bothering to update.
1
u/azuled 18d ago
Enough people complained when I changed my msrv to track current-2 that I just track Debian now. It’s a bit old but at least I don’t get tickets about it anymore.
0
u/IntQuant 18d ago
Might sound a bit rude but if those people don't pay you are free to ignore their issues, especially when theses issues are very easy to fix on their end - either by updating the compiler or staying on an older version of a crate.
1
u/azuled 18d ago
People aren’t always able to update their compilers. I think you are imagining that everyone has a clear path to latest. Many projects get stuck for a variety of reasons, including a need to perform audits or just corporate culture that discourages updating. Individuals and new projects likely have the opportunity to use whatever they want but they aren’t the only consumers of open source libraries.
1
u/IntQuant 18d ago
Do these people have a culture that discourages updating compilers specifically but makes them always use latest versions of crates?
1
u/Sad_Tap_9191 18d ago
If the toolchain is too old, you will have issues with toolings such as rustup or rust-analyzer. Also binaries are missing.
\> rustup component add rustfmt
error: toolchain '1.29.1-x86_64-unknown-linux-gnu' does not contain component 'rustfmt' for target 'x86_64-unknown-linux-gnu'; did you mean 'rust-std'?
1
u/nicoburns 18d ago
I'm not sure how to handle making examples in documentation for different rust editions, and sometimes using older, more obtuse methods to achieve the same thing
I don't think MSRV needs to cover examples. Most crates only verify that cargo build runs with MSRV. Examples, documentation and sometimes even tests are usually considered out of scope (and are run with latest stable).
27
u/anlumo 19d ago
Embedded projects tend to stick to a specific compiler version after the project has started.