- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or # to comment.
An LTS release scheme, combined with encouraging libraries to maintain MSRV compatibility with LTS releases, could reduce this friction.
This actually sounds like a good idea. Currently crates are choosing their MSRV all over the place. If we just got a bit of alignment by calling every ~17th Rust release (roughly 2 years worth of releases) an “LTS” release, then crates could be encouraged to keep their MSRV compatible with that release.
But we also heard a consistent shape of gaps [in core]: many embedded and safety-critical projects want no_std-friendly building blocks (fixed-size collections, queues) and predictable math primitives, but do not want to rely on “just any” third-party crate at higher integrity levels.
I think some fixed-size collections and stuff like that would be super nice in core. Something with simple, predictable semantics, just like Vec has (i.e. no optimizations for certain usage patterns, like small string optimizations and that sort of stuff). With const generics working for integers, fixed size collections in core shouldn’t even be that hard (it’s certainly been done in many crates already).
This actually sounds like a good idea.
I strongly disagree. I’m going to quote myself from reddit here:
Why would you expect to be able to use an old compiler and new crates? Shouldn’t you just pin everything to the old versions? The MSRV aware resolver (that we had stably for a year now) makes that seamless. I don’t see why they expect to be able to eat their cake and have it too.
This comes up again and again by LTS fans, be it safety critical or Debian packages. Yet no one have managed to explain why they can’t use a new compiler but can use new crates? Their behaviour lacks consistency.
And from a later reply:
Now if they want to fund the maintenance in question, that is an entirely different question (and would be a net benefit for everyone). But that tends to be quite rare in open source. https://xkcd.com/2347/ very much applies.
I found the discussion quite interesting over all: https://old.reddit.com/r/rust/comments/1qcxa9o/what_does_it_take_to_ship_rust_in_safetycritical/ (it is a shame lemmy is so much less active than reddit still).
I think some fixed-size collections and stuff like that would be super nice in core.
If you don’t mind using a crate: take a look at the well regarded https://lib.rs/crates/heapless (but yeah, having it in core would be nice, but might be too niche).
I don’t agree with the comment there. In my mind, the LTS release would not mean anything. It would just be a label on an arbitrary release every couple of years. I feel it could help the ecosystem align on which MSRV to choose, so that you don’t have one crate choosing 1.x, another chooses 1.(x+1) and another chooses 1.(x+5). It would be nice if we just sort of agreed that if you care about your crate being used by somewhat older compilers, use the LTS version and consider the implications if your MSRV go beyond that version.
Of course any crate author is free to completely ignore this and choose whatever MSRV they desire. But perhaps a significant amount of authors would put at least a little effort (but not much) in trying to avoid raising the MSRV above the LTS version, just as authors may try to avoid breaking changes and such. It’s just a nudge, nothing more.
I think having “LTS” mean nothing is counterproductive. Why would anyone agree to apply “meaningless” labels like that? It would only confuse people more if we applied a label which implied support but nobody was actually obligated to support it any more than another release.
