Possible LTS releases tied to editions?

It’s important to differentiate what people say when they mean LTS. There’s roughly a split into two groups.

  1. People that want a stable focus point. For example, you want a release that can be used as a base for software shipped with a certain distribution. These people need a cut-off point where they stop using new features and can be half-way sure that a wide base supports this version of Rust. It’s kind of an in-between of a service to distributions and users. This establishes something that Rust is currently lacking - forward-compatibility on an ecosystem level. An LTS could lead to a point where many base libraries agree on supporting Rust LTS, and only custom products opting into newer versions. Tuning this to the cycles that distributions have is probably the best way to do this.

  2. People that need long term support for business reasons. For example: you produce a certified firmware. They basically want their toolchain in an icebox. They don’t necessarily care for “the official LTS version”, they care for not upgrading the version used in a product, as any upgrade would incur certification costs. Also, usually, the time frame for this is nothing that a FOSS project can reasonably provide. It only makes sense as a commercial service[1], IMHO. A usual model here is though that people take the official LTS version as long as they can get and then get a support extension.

[1] Sorry for the advertisement, I happen to offer that.


I’m strongly against using editions for this. Editions allow code to lag behind the language evolution, so that the language can evolve faster. Using editions to allow compilers to lag behind language evolution will achieve the opposite effect!

Editions allow:

  • library authors to adopt new features without losing compatibility with laggard projects.
  • projects to adopt new features without losing compatibility with laggard libraries.

LTS compiler completely flips this around and IMHO ruins the whole point of editions:

  • library authors will not be able to adopt new features faster than the slowest LTS projects.
  • projects will not be able to adopt any new features without waiting for a new LTS compiler edition.

Most LTS users wont be publishing LTS crates. We don’t need to care about their impact on the ecosystem.

Editions provide a useful anchor point because we plan learning materials around editions.

I mean it in context of LTS users consuming crates.io crates, not publishing.

If users with very old compilers are officially supported by Rust, as a library author, I will need to care. Currently I have the luxury of targeting a recent stable version. If Rust LTS becomes a thing, I will have to think how many users I’m excluding because they were told it’s OK not to update the compiler for 2 years.

It’s the same with use of C99. Authors of libraries still shy away from C99, because not everyone can use it.


I don’t think that’s an issue, because the LTS users will not be updating their crates except for security bugs (out of the same reasons why they won’t be updating their compilers). So they get all their crates in the first months of development and then they’re mainly maintaining.


I’d love to have us have some sort of LTS channel at some point.

However, as this thread talks about, “LTS” means different things to different people. I think it’s really important that LTS is about artifacts. This makes it completely distinct from editions. Now, there may be some value into making sure that the release cycles make sense, but that’s more of a strategic issue than what the LTS is fundamentally about. Remember also that new features can often land in older editions as well, and that new features will continue to land in Rust 2018 in the future; so saying that we will freeze “based on an edition” is a bit non-sensical, IMO.

What I’d like to see is an LTS model where it’s another train; just like not every nightly becomes a beta, not every stable will become an LTS. At first, the LTS release cycle would be fairly short; over time, we lengthen it. LTS also means backporting security issues, and not general bugfixes. Again, possibly moving to more in the future, maybe.

This also does apply a reasonable anchor for the ecosystem as well.


What release interval do you have in mind for LTS releases?

I’d image that security patches can only be backported so and so far. I’m not familiar with the compiler internals, but with all the work like MIR, non-linear lifetimes etc. I’d image that there’s a lot of churn that makes backporting security fixes hard.

The main reason I want to tie it to editions is that each LTS would be accompanied by a docs refresh, mainly.

Rust 2018 is a milestone for Rust – it produces a coherent picture of “new Rust” accompanied by a bunch of features and mental models, which will be incorporated into the docs. I think there’s value in leveraging this for LTSes.

1 Like

That’s what I was thinking, too. If Rust is going to be used in safety-critical environments, or in Linux distributions, or if crate authors are going to fix their minimum required compiler version, then people are going to be using old Rust compilers. The advantage of making officially supported LTS releases is that you encourage everyone to use the same old compiler, instead of Debian, Firefox, Dropbox, and Microchip all picking different ones.

I definitely think Rust should get LTS releases. I’m not sure, though, if it should get them yet.


LTS is important for enterprise and Business Services Users, Of course It 's sure to do it. Like Nodejs, with the LTS appear, The Business adoption rate has soared

It’s also only a starting point; rust continues to evolve and so does each edition. Let’s say it’s 2019 and I’m using const fn in stable Rust 2018; if I was using the “Rust 2018 LTS” it wouldn’t have it in there. This is pretty confusing.

I think your point about being after a docs refresh, etc, is a good reason to choose strategic timing for an LTS, if that’s the kind of thing we were going to do, but directly tying it to an edition has too many problems.

I also don’t think we’re ready for a three year long LTS release.


“strategically timing” them with editions is mostly all I was going for, though I felt that naming them the same would be useful too.

1 Like

I think Rust shouldn’t do an LTS.

An LTS would undermine the “stability without stagnation” story in two ways. First, it would signal that the “stability” part isn’t really true, because otherwise an LTS wouldn’t make sense. Second, it would cause stagnation as people would think their software needs to work with the LTS.

An LTS also seems very premature in a situation where so many use cases don’t even work on the stable channel and require nightly.

Futhermore, I worry that having an LTS would set the expectation that crate authors should do the work to support at least the most recent LTS. This either means more work or stagnation arising from not adopting new Rust features before they reach the LTS channel. Either way is harmful from the point of view of keeping Rust moving forward.

In terms of setting expectations, it matters who does an LTS. It seems to me that when a commercial enterprise Linux distributor decides to support some snapshot of software versions, it’s well understood that that’s how the enterprise vendor makes money, so they are on hook for the effort to make stuff work in such a snapshot environment. Also, since you have to pay, the users are rather invisible behind enterprise walls and don’t bother the larger community that much. However, when an LTS is perceived as a community effort, there are more people using LTS when they don’t need to be using LTS and more sense of entitlement to have members of the broader community who didn’t sign up to support an LTS to support the LTS nonetheless. In this sense, I’m much more worried about an LTS that’s perceived as a Rust community effort or effort by a community Linux distro than I am about commercial enterprise Linux vendors doing an LTS for their customers in a way that crates.io crate authors don’t even see from the other side of the firewall.

In the case of Firefox, I’m worried that a Rust LTS existing would result in pressure from the Linux distros to make Firefox stick to LTS Rust instead of updating Rust every six weeks. At a time when Rust is in active development and Firefox discovers needs for fixes in the toolchain, being artificially limited to an old toolchain would be harmful. OTOH, now that an LTS Rust doesn’t exist, the Rust ecosystem gets to benefit from Firefox requiring even generally non-rolling distros to ship a semi-rolling Rust in order to keep building Firefox. (It looks like Ubuntu 14.04 has Rust 1.22.1 at this time. It’s not the latest Rust, but it sure is newer than what existed in April 2014.) It would be a strategic blunder in terms of avoiding stagnation in the Rust ecosystem to volunteer to give that up.


There’s a lot more to LTS than simply language stability. There’s stability in performance; there’s stability in the dependencies the toolchain has on the host system. For Linux distros that want to dynamically link all their Rust packages with the same version of libstd the same way they do with libc, there’s also stability of dependencies of the toolchain itself.

I’m sure at some point rustc will mature enough that those kinds of things will also stabilize. But there’s no goal to do so, they’re not considered part of the stability guarantee, and yet they’re still important to some people.

On the other hand, maybe an LTS doesn’t make sense because those things still change so much. The Firefox example is a good one, I think. But this is still something to be aware of- if we want to provide an LTS release at some point, it would be to provide these additional forms of stability.

1 Like

I doubt that a Rust LTS by the Rust project rather than a distro would solve anything in that area at this time. Distros appear to be packaging Rust apps the way they package Go apps: Dependencies as source to enable in-archive builds, but the app is statically linked. There doesn’t appear to be huge pressure to change that at this time. Also, an upstream doing an LTS doesn’t mean that distros will trust the upstream to do exactly what the distros feel they want. (E.g. Ubuntu LTS ships their own LTS kernels and not kernels from a kernel.org LTS branch. Debian does their own versioning for security patches on top of whatever shipped with a distro release originally, etc.)

As a RHEL maintainer, I accept the burden of maintaining whatever version we snapshot for the duration of our support period, as you say. But note that we’re also not putting rustc in the base OS yet, only in the devtools SCL products that have a shorter support period. (But it can also get more frequent rebases that way.) Since you mentioned Ubuntu 14.04, note that rustc is in “universe” there, which community-maintained.

I am more concerned about the broader community though. I do think that crate authors should care about long-term compatibility, and I think it’s too dismissive to call enterprise users “invisible” or walled off. Enterprise developers certainly do write new software with their stable (old) tools, but I think they’re going to be less likely to choose Rust if the crate ecosystem is too much of a pain to find compatibility.

Take a look at popular C++ libraries – how many of them now require C++17? C++14? We may finally be to the point where at least C++11 is generally required. Yes, Rust is still quite young, but if it wants to move into such software domains, it will take some effort to understand those kinds of expectations (even as it pushes back new expectations).

Sorry if this is too rambling. I’ve had it in mind for a long time to write some kind of RFC for a Rust LTS/ESR/whatever, so I’m happy to see this thread, but I don’t really know what all the answers should be. It’s hard to balance this desire to use shiny new features against the stability needed for long term software maintenance.


In general, yes. However, universe is also the place where Firefox-required toolchain backports go. For comparison, the gcc-mozilla package lives there, too.

That was meant as a positive statement about the less entitled attitude of RHEL users relative to the more entitled attitude of (some) Debian stable users. (Note users rather than maintaners in that sentence.) The logic goes that since Debian is a community project, the larger community should help enable Debian users to build new upstream software with the old toolchain in Debian stable. As noted, the relevance to this discussion is two-fold: 1) if an LTS isn’t behind a commercial subscription, there are more people who use LTS without a very serious need to do so leading to LTS appearing as a bigger addressable audience creating more pressure to hold new software back in order to be compatible with the LTS and 2) when the LTS is perceived as a community effort, people feel it’s more OK to ask the larger community to bear the externalities of the LTS.

My conclusion from this is that Rust should treat the C++ situation as something to avoid. It’s super-sad that in 2018, when the latest GCC, clang and MSVC are a download away, stuff like Abseil enabling users of C++ stick to C++11 while backporting some newer features is perceived as a valuable thing.

That is, I think Rust should identify what it is that makes people shy to take a free-as-in-beer compiler upgrade up from C++11 and then avoid making the same mistake in the Rust context so that we can get users of Rust to keep upgrading rustc instead of the library writers diverting effort into enabling them not to.


Frankly, there is no such thing as a problem-free upgrade in the general case. Even rustc’s relatively strict language-stability policy has exceptions. The larger a system gets, the more likely it is to run into those exceptions. At some level, those systems are going to delay upgrades so they can schedule the inevitable work they will require.

And even if you could solve all of those problems (and I hope we can eventually!) there will still be logistical problems. In a large organization, you have a bunch of dev machines, a bunch of CI infrastructure, etc. and it all has to be updated at the same time because Rust’s ABI is unstable.

I suspect that as Rust grows we will see more LTS-like behavior even if there’s no official LTS release. So while I don’t know if it’s worth making one, it feels inevitable that people will want one.


Which is why the idea of an LTS release of the compiler is meaningless. You either are prepared to fully test and validate your software when it is built with appropriate automated and manual tests or you aren’t. If you are, then using the next compiler version, which, due to the Edition System is guaranteed to be backwards compatible, is a trivial matter. If you aren’t, then even applying a bug fix to the compiler version, hell, even changing an optimization flag or building on an updated CPU, is a complete unknown as to whether or not your software is reliable.

I just don’t see what the idea of LTS, separate from the Edition concept, brings to the table? I’m going to freeze at some Edition/Compiler version, call it an LTS, but, then apply bug/security fixes to it and rebuild my software with confidence that??? What??? It doesn’t make any sense whatsoever. I’m sorry, the whole concept is just utterly and completely flawed and doesn’t even have internally consistent logic.

Why the hyperbole? You’re clearly missing whatever it is that drives people to use LTS releases of their software, so maybe chill out for a minute and think it through.

For example, maybe those bug fixes are much smaller in scope and easier to re-validate? Maybe they happen less often and can be re-validated in batches? Maybe they don’t need the level of validation that you assume? There are a lot of possible explanations, and denying reality is unhelpful.