The qualified Ferrocene toolchain has "2 years of patch releases for select versions", so they have 2-year LTS releases, but that's a paid support plan.
Overall, the Rust community hasn't felt much need for official LTS releases.
Can you really call it stable if it is updated every 6 weeks?
This is what the Rust project means by stable. You can update and your code will continue building. (There's a bunch of documented caveats though.) Rust has been stable in this sense since 1.0, almost ten years.
Of course, you might have different semantics for "stable". Some seem to mean "rarely updating" or "each update is small" by that. In the latter sense, too, Rust has becoming stabler over the last few years.
In the "rarely updating" sense, Rust is not going to change course. Frequent, time-based releases have demonstrably made the progress smoother, and in a sense, "stabler", as in, more predictable and bug-free.
What makes Rust special over other programming languages and operating systems and software systems that have LTS releases? For example, .NET and Ubuntu have LTS releases.
LTS releases are for things which end up in your runtime environment. Compilers typically don't have LTS releases because there isn't much room for critical bugs which aren't discovered for a long time. Rustc (as with most AOT compilers) does not attempt to be safe to use on untrusted source code, so a bug when it's given a malicious file isn't a security vulnerability. It's theoretically possible for rustc to have a codegen bug which causes security problems in the code which it compiles, but in practice such things don't really happen and there's nothing unsafe about using a ten or twenty-year-old build of a compiler.
LTS releases of the rust standard library could potentially need to become a thing. That could have bugs which need to be backported to old versions, and I assume it just hasn't really come up yet.
There's Python 3.10 code out there that won't run under 3.13, especially so if it relies on components written in C that use Python's C API. If you didn't have LTS releases for Python, you'd have a choice between constantly having to port your code to run under the latest Python version or using an older, insecure one.
Rust doesn't have this problem, old Rust code should compile just fine under newer versions of the compiler and stdlib.
Lets take an existing edition first, in Rust 2021 Edition (what you get today out of the box when you just start writing Rust) the array types impl IntoIterator. Which makes sense, why shouldn't I iterate over this array with a for loop ?
But, Rust 1.0 could not possibly have provided this, how would it work? It didn't in Rust 1.0 you can't make an array into an Iterator.
Now, if this was some obscure rarely used feature maybe you'd just say "Who cares" but this is IntoIterator which is used to make for loops work, so that's high profile. So in fact what happens is that a modern Rust compiler (in which there even is a 2021 edition) knows that in earlier Editions it should pretend that arrays did not impl IntoIterator. You can loop over them just fine, but mysteriously they don't impl IntoIterator, so that code which used to mean one thing (because they didn't implement this) still means what it used to.
So that's an example of seamlessly making Rust 2021 edition have better semantics and yet all the old software still works.
In 2024 edition the semantics of certain RPITs (Return Position Impl Trait, an existential type) with respect to lifetimes are expected to change. In most cases either what you wrote already is technically wrong but will now be correct, or, what you wrote was wrong but you got away with it and now you'll get told you got it wrong if you move editions.
Editions is not a panacea but it's vastly better than the previous status quo, look at how miserable the situation is in Java, in C++, in Python. Vastly different approaches, worse results on all dimensions.
Additionally I have my doubts how long this will scale when Rust has like 40 years of history behind it.
We've been doing this for 10 years already, so if the cost is linear, it shouldn't be a problematic burden over another 30 years. It helps that editions don't need to be big. Just checked the codebase and there are exactly 70 gates for "at least edition X" (2018 21, 2021 19 and 2024 30) and 16 for "is edition 2015" (2 in the parser, most of the rest in name resolution).
As someone else already pointed out, this is incorrect. Installing the .NET SDK is how you install C# and F#, and both the C# and F# language versions are tied to .NET versions. Since .NET has LTS releases, so do C# and F#.
My original comment already addressed why I mentioned Ubuntu. I didn't claim it was a programming language, and it doesn't matter that it isn't. In fact, that was the point of mentioning it.
> Compilers typically don't have LTS releases because there isn't much room for critical bugs which aren't discovered for a long time.
Having an LTS release doesn't mean that it doesn't get any bug or security fixes. It normally just means that it doesn't get new features.
Not only do they depend on CLR changes, they also depend on the BCL that is shipped alongside.
ABI stability for one.
For one, providing approved and certified toolchains for safety-critical systems.