Possible LTS releases tied to editions?

[Manishearth]

I know folks have asked for LTSes before.

The idea of an LTS (“long term support”) is that we have a certain release that we freeze, and guarantee to backport bugfixes for for a certain severity level. For example, Ubuntu has releases twice a year but they do a new LTS every two years. Old releases lose support pretty quickly, but LTSes keep being supported till the next LTS.

Firefox does something with ESR (“extended support release”) releases with a new ESR every year (the regular release cycle is 6 weeks, like ours).

Given that we’re doing the edition soon, it might be worth piloting an LTS program with this. The idea is that we designate a certain release of the compiler – perhaps the release ~4 cycles after the edition – as “Rust 2018 LTS”. We guarantee to support this till the next edition, and define the level of severity for bugs to be backported.

Thoughts? I’m mostly just interested to see what the needs actually are for LTSes.

[aidanhs]

On LTS in general: I restrict myself to Ubuntu LTS because I’ve been burned too many times by updates breaking my hardware and software - a month after LTS release I install it and sit on it for two years in the hope of lower risk. I assume a Firefox LTS is useful for IT departments not wanting to update deployment scripts every 6 weeks (fair, and I know I’ve used Ubuntu LTS for servers for a similar reason).

I could see an LTS distro like Ubuntu picking up the LTS Rust, but:

1. The language is still evolving! There’s a disincentive to stay on LTS if you can’t use the latest cool features (nightly and stable used to have this issue). Relatedly: will library authors target it? If library authors don’t bother then it’s not a very useful compiler - consider one pre-dating ?.
2. The backcompat story for Rust in general is pretty good, so upgrading is generally without fear. This is just…not the case at all for any Linux distro.
3. From an effort perspective, I’m not sure how viable it is - we’re already talking multiple ‘streams’ of bugfixing (two editions), now we need to double that by deciding which fixes for which editions come back?

To be clear, I see the point and I can imagine there being a nonzero number of people who get real tangible benefits from it. Is it worth doing it given the factors above? Not sure.

[josh]

Honestly, my first reaction is “isn’t Rust already long-term stable”? We shouldn’t be breaking things in a stable release. Let’s not set the precedent or encourage the belief that we need a “long-term” stable release, lest that become self-fulfilling.

What specific requirements have people put forth when they ask for an LTS?

[Manishearth]

Folks want a stronger kind of stability, the stability from any language changes. This is usually useful for folks with closed environments where they wish to pin a toolchain.

(Also, at Firefox’s scale, we’ve been regularly bitten by Rust’s breakages, so I’m a bit skeptical of this in general. It’s always minor, but still a hassle.)

[H2CO3]

Strong yes from me, and also please make an LTS for a relatively recent version of Rust 2015. I can hardly imagine myself forcibly upgrading to Rust 2018 in already-existing Rust 2015 projects. (Nor will I start new project with the new edition probably, but that’s another question.)

[Nemo157]

I can hardly imagine myself forcibly upgrading to Rust 2018 in already-existing Rust 2015 projects.

All future compilers will support Rust Edition 2015 still, even Rust 1.94 which also supports Rust Edition 2021 and Rust Edition 2023 will still compile all existing Rust Edition 2015 code with the same guaranteed semantics as Rust 1.26 does today (it may apply more optimisations, but those will not break existing correct code, where all safe code is guaranteed to be correct).

[skade]

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.

[kornel]

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.

[Manishearth]

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.

[kornel]

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.

[oli-obk]

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.

[steveklabnik]

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.

[MajorBreakfast]

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.

[Manishearth]

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.

[notriddle]

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

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.

[krircc]

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

[steveklabnik]

Rust 2018 is a milestone for Rust – it produces a coherent picture of “new Rust” accompanied by a bunch of features and mental models

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.

[Manishearth]

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

[hsivonen]

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.

[rpjohnst]

First, it would signal that the “stability” part isn’t really true, because otherwise an LTS wouldn’t make sense.

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.