pre-RFC: LTS for the Rust Toolchain

internals policy
1

Disclaimer: I am proposing this as part of my employment at Canonical[1]. I am representing an interest of Canonical, but I am not representing Canonical itself.

Intended Improvements
  • Send out a Rust Survey asking what actual potential users' expectations are for a prospective Rust LTS in terms of frequency, support duration, cost, et al.
  • Revert the "When to use LTS" back to "User Explanation" with two subheadings: "The LTS Target Tier" and the existing "When to use LTS" heading.
  • Add illustrative requirements for LTS Tier target support to the technical explanation.
  • LTS does not imply MSRV policy. Ecosystem crates, including Rust Project published crates, continue to target stable by default and keep their independent policies on how frequently they expect downstream to update the toolchain to get new library releases.
  • Future work: coordinating with distros to deliver rustup managed toolchains through the OS distro mechanisms (optionally).
  • Future work: (unbaked) Ecosystem Rust LTS where ecosystem OSS projects can sign up to offer support contracts through the Rust Foundation and receive funding for the LTS work.

I'm very aware of the volume of discussion that has gone into potential LTS releases. The primary purpose of sharing this is to share my documentation of the why behind the requests for LTS

Summary

The Rust stable toolchain has been supported since 2015, and the Rust Project continues to offer support for stable Rust with no current plans for end-of-life. However, the Rust Project acknowledges that stable Rust releasing a new semver-minor release every six weeks can be more update risk than conservatively slow-moving enterprise users are willing to adopt.

As such, each year moving forward the Rust Project will designate the second minor release version of the toolchain that year (e.g. 1.103) for long-term support (LTS). LTS releases will receive security patch releases for at least one year plus one full stable release cycle (i.e. at least 60 weeks or roughly a year plus eight weeks).

This year of LTS is maintained by the Rust Project and licensed identically to the other toolchains distributed through Rustup by the Project without warranty of any kind such that the open source community can coordinate on supporting one LTS target. If you require a longer support term or a formal support contract, contact the Rust Foundation; they will help connect you with organizations able to provide that support.

Motivation

Rust is increasingly getting used to build software that offers long term support (LTS). Of course, an LTS compiler toolchain is not a requirement for building LTS software[2]; if your LTS requirement is just “don’t break user workflows,” it doesn’t matter if the method by which you build your code changes. Rust stable already offers a very strong stability guarantee, meaning that updating the toolchain for an actively developed project is painless.

Unfortunately, when dealing with enterprise-scale software and LTS timelines, Hyrum’s law becomes a problem: every change, no matter how obviously correct, can break something. Rust’s API evolution policy necessarily allows for some changes that have the possibility to break downstream consumers. How confident can you actually be that nowhere in your software or its transitive dependencies relies on an inference quirk that might have a change in its behavior within the next decade?

Using an LTS compiler is a risk mitigation strategy for LTS software which is only receiving security patches to fix CVEs and other issues of similar severity. The underlying value proposition is that it will be less work overall to backport CVE fixes to LTS compiler versions than it would be to update the compiler and then have to diagnose and fix minor breakage issues in code nobody has touched for five years.

Furthermore, certain conformance requirements can require all used software to have defined support and end-of-life timelines. While the Rust Project does not necessarily need to be the one defining those timelines (e.g. a company with such requirements could use the Ferrocene qualified Rust toolchain, which has support timelines defined by Ferrous Systems), having an LTS timeline endorsed by the Rust Project directly improves ecosystem centralization around a single standard timeline, visibility to companies asking for "LTS Rust," and means that security-sensitive users only need to trust the Rust Project and not an independent redistributor providing the LTS they require.

For many companies, using LTS will be a checkbox instead of a genuine need, and the stable toolchain actually fulfills all of their stability and support requirements. The inability of the Rust Project to enter a legally binding support contract might result in the Rust Project provided LTS not being enough for some applications where legal culpability for damages caused by lack of support is required. But even given that, defining an official timeline for long term support provided by the Rust Project serves a legitimate need that is becoming increasingly pressing as more enterprise entities are adopting Rust.

Risk tolerance

(adapted from Julia's release process)

Users of the toolchain fall into one of four risk tolerance categories:

  • High risk tolerance: Lives on unstable, helps find bugs when they happen.
  • Normal risk tolerance: Wants things to work and likes new performance improvements. Uses stable. Blames the library when a stable update breaks a library; the library was relying on things that the toolchain doesn't guarantee caveat-free stability for.
  • Low risk tolerance: Prioritizes minimizing risk over other improvements. Uses LTS. Willing to upgrade to the next LTS release once it has had some time to mature. May blame the toolchain before the library if updating the toolchain (within a given LTS release) breaks something.
  • Very low risk tolerance: Never updates anything except for critical fixes, as the stability of never changing anything is preferred over anything else. Uses whatever version they need to think the least about. Willing to either fix things themselves or pay for fixes when they become necessary just as long as they don't need to update anything except to get that one targeted fix.

Our existing release channels serve the first two categories extremely well. The fourth category isn't the type of user the Rust Project necessarily wants to support, and are capable of finding support elsewhere. The third category is the target of our LTS support.

This category of risk tolerance is also the reason we choose this LTS cadence. The LTS support period is deliberately longer than LTS release cadence so that LTS updates can be done before the prior LTS is out of support.

When to use LTS

TL;DR: Don't, unless an external conformance requirement spells out that you MUST NOT use the stable toolchain. If you aren’t sure, use stable. Almost all of the time, you should not be using the LTS toolchain; stable gets bug fixes and performance improvements to both the compiler and to the output compilation artifact (i.e. your application) that will by design never be released to the LTS toolchain.

If you are developing features for your production software, use stable. Update your package.rust-version (and your cargo dependencies) regularly as a normal part of your development process. The risk of a nontrivial upgrade for a project in active development is negligible, especially if you update often.

When you are maintaining LTS for your own application — that software is receiving no development except for patching security issues as they are discovered — then you may want to adopt the LTS toolchain as a risk mitigation strategy. When requirements for delivering your own LTS are to change nothing about your application or its build process except as strictly necessary to stay in support and patch security issues, then you know already you need LTS. If you don't have a strict requirement for an immutable build process — the threat model requiring such is niche[3], and updating the toolchain used to build it has no impact on your application's user-visible LTS guarantees[4] — then you should still use stable.

Libraries deserve a special mention, as they may want to make themselves available to downstream users that are using the lts toolchain and/or offer their own LTS release channels for specific minor release versions. For such cases, we recommend these guidelines:

  • NEVER offer LTS or target the LTS toolchain for a package with a major version of zero.
  • Updating [package.rust-version] to exclude a supported LTS toolchain version is a minor-level change. Updates to [package.rust-version] that do not do so are patch-level changes.
  • Once a minor release series is designated for LTS, further releases in that series MUST NOT contain any minor-level changes (nor major-level changes) as defined by the Cargo Book on SemVer Compatibility, nor any potentially-observable changes to their build configuration.
    • Packages with clear documentation of such MAY relax these requirements ONLY IF doing so for the purpose of offering continuing support, such as when the underlying system support changes.
  • If the package offering LTS wants to continue feature development, it MUST be performed on a manifest-declared version of the package not in the same minor release series as the LTS.

Note that a package being major version 1 (or higher) does not mean that it provides long term support, nor that the author wants to provide such. Furthermore, the entire point of LTS releases is that they see no development other than security patches. If you want access to the most recent improvements to the Rust toolchain and libraries, you should not be using LTS release of the toolchain.

If you are a consumer of applications built using Rust, whether the Rust toolchain is LTS has no impact on the support of the software. If your software vendor or other requirements require you to compile the application yourself, use whatever version of the toolchain your software vendor tells you to use or latest stable if they don't.

Technical explanation

The support that the Rust Project offers for the LTS toolchains is limited to patching security issues reported to the project. Repackagers of the Rust toolchain are encouraged to build their own LTS offerings on top of this support in accordance with the Rust trademarks.

This policy does not extend the existing toolchain support policies beyond adding the LTS toolchain versions to the list of supported toolchains. Support for components within the toolchain continues to follow the existing support tiers policies, and Rust Project artifacts delivered outside the toolchain (such as libraries delivered via the crates.io Cargo registry) are not covered by this policy. Furthermore, the Rust Project is not a legal entity capable of entering a support contract, and this policy MUST NOT be construed to provide warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and noninfringement.

No new channels are added to the rustup distribution at this time. Users of the LTS toolchain can use the existing versioned 1.X channel.

Drawbacks

Offering long term support means work spent patching old releases of the toolchain instead of developing the current version. Arguably, nobody should actually use the LTS toolchain, as the stable channel guarantees should be sufficient for building software with long term support.

Officially endorsing an LTS toolchain also runs the risk of delaying adoption of new stable toolchains. The guidelines on when to use the LTS toolchain are designed to mitigate this risk, but external pressures to work with LTS toolchains may develop.

Also, of course, this is signing the Rust Project up for more work backporting security relevant fixes to toolchains up to five years old.

Rationale and Alternatives

LTS outside of the Rust Project

See the motivation section; the benefit of endorsing a timeline as part of the Project is real. Even if the Project doesn't want to provide the LTS for free like all products of the Project are, defining what "Rust LTS" means inside the Project confers benefit to coordination outside the Project.

Furthermore, the customers who want the "LTS" version are those most likely to be willing to pay real money that can go towards supporting both that effort and towards the active development of Rust. Since LTS customers might also require a support contract, one alternative is to provide LTS through the Rust Foundation, since they have the legal framework to both charge for and sign such support contracts.

Charging for LTS licensing

The Project's LTS could be licensed under a non-commercial and/or copyleft license such that the open source community is free to use it while still requiring commercial enterprise customers to pay for LTS. This seems monetarily advantageous to the Project, but may goes against the existing open licensing ethos.

The RFC author explicitly provides no opinion nor guidance on whether this is legally viable.

Reactive instead of proactive support

The support promise as defined above is to backport any security relevant fixes once they're available to the LTS toolchains. An alternative is to instead offer support on demand: guarantee that a backport will be done for security-relevant issues when and if it is requested. This does align better with providing LTS for a fee but giving the support away for free once it exists.

However, it is the author's opinion that it will be less work overall to do the patching proactively. With the above timelines, only a maximum of two toolchains are in LTS at any one time, and backporting proactively means that it's done when the fix is fresher in the minds of those who worked on fixing it.

Aligning LTS to editions

Rust already has an existing multi-year cycle in editions, which are released roughly every three years. We choose here to deliberately not tie LTS to editions, as LTS and editions serve two different orthogonal functions. The edition cadence is not considered stable, and as such we should not tie

That said, releasing LTS versions the year before an edition year and timing edition EoL to edition releases (so LTS every three years supported for four) is a strong alternative for the messaging affordances.

Longer LTS periods

Only providing just over a years' support is chosen to minimize the not-directly-paid-for maintenance burden on the Rust Project. A longer LTS period almost certainly requires sponsoring from customers that want that LTS. Furthermore, once the Rust Project officially designates a release as LTS, the community beyond just the Project can organize around it to provide support if the demand is there.

More granular policy

Node.js defines multiple LTS-related periods. Notably, they separate "Active LTS" from LTS, with the "active" version being the most recent version in LTS, along with keeping the most recent as "current" for six months before promoting it to LTS.

This seems like more effort than it's worth for the Rust Project given Rust stable's already very strong stability promise and release trains. If users want to delay their adoption of an LTS, that's their choice, and the Project doesn't need to tell them to.

Prior art

Other language/toolchains' LTS:

  • Java SE: Every 2 years with 5 years' support
  • .NET: Every 2 years with 3 years' support
  • Node.js: Every year[5] with 3 years' support
  • Julia: No defined cadence/timeline yet. In practice, ~3 years with no overlap.

Prior discussion:

Unresolved questions

  • The exact release frequency and support duration of LTS is contentious.
  • Would the intended LTS users even want to use the toolchain distributed by rustup?
  • What avenues for monetization of LTS are available to the Rust Project?
  • How long do prospective enterprise LTS users expect "LTS Rust" to be supported for?
  • How much would prospective enterprise LTS users pay for "LTS Rust" without flinching?
  • Are the prospective enterprise LTS users willing to put their money where their mouth is?
  • How do we create a "pit of success" for choosing between stable and LTS?
  • What will actually be the added workload for Rust infrastructure providing LTS?
  • Further unknown unknowns abound.

Future possibilities

Nothing within the Project is really enabled by LTS. Support outside the Project also doesn't require us to define LTS, as shown by Ferrocene. The possibilities opened by LTS are ones of further adoption of Rust and the results of such.

However, we can of course choose to extend this policy to provide more and/or longer LTS in the future.

  1. I got hired to help develop the Rust Project on behalf of Canonical! I join the list of people getting paid to work on Rust itself :tada: (along with work on how Ubuntu redistributes and uses Rust) ↩︎

  2. Responsibly building LTS software does require that the compiler toolchain be supported. But this only requires support over a long term; it does not require the feature freeze that is implied as part of calling a release LTS. ↩︎

  3. Justifying the use of LTS for security threat model reasoning requires that you trust the releases pushed to the LTS channel but not releases pushed to the stable channel, despite the same entity being responsible for distributing both. Unless you are reviewing every patch to the LTS compiler AND bootstrap-compiling the patched versions yourself, you have extremely weak grounds for using lts for security reasons. ↩︎

  4. It deserves repeating: delivering LTS software does not require using a build process with feature-frozen LTS; it only requires a stable build process with continuing support, which the stable release channel provides. The partial exceptions that can apply with other languages with respect to application "plugins" don't apply to the Rust toolchain, as Rust provides identical stability across both semver-patch and semver-minor updates. ↩︎

  5. Starting with the coming 2027 release; every two years before 2027. ↩︎

7 Likes
2

I think having companies financially support an LTS version (i.e. be actual "customers") would be a necessary prerequisite for the project providing an official one. So in my mind the question becomes: is that something the project can do and what would it mean for the project if it did.

We don't currently sell support for the stable toolchain (should we?) so I think this would be new in a number of different dimensions.

9 Likes
3

What kind of fixes should the LTS contain? Only security fixes to the standard library and cargo? (what if there is a security issue in the LTS, but it got accidentally fixed on main and thus anyone looking at main will never notice that LTS contained a security issue?) Bugfixes to the standard library (which ones? bugfixes can also break things) Soundness issues? (Those often depend on refactors of compiler internals that are the main cause of the very bugs an LTS is supposed to avoid) I think there will be a lot of differences between people about what they actually want from an LTS.

Edit: Never mind you already answered security fixes. It does leave the question of what to do when a security fix itself requires a breaking change.

Our support and end-of-life timelines are effectively the following: Rust 1 is supported since 2015 and expected to be supported for many years to come. Rust 1.95 is just an update to Rust 1. :slight_smile: Do those conformance requirements have any bounds on what an update is allowed to be that would forbid adding major new features?

If anything using an LTS will make this much more painful as now you may be forced to update a lot of dependencies all at once and possibly across several major changes to their api, while following stable fairly closely will allow you to gradually update as necessary.

Also this will put strain on the wider ecosystem by having those users of the LTS version demanding a much lower MSRV than could otherwise be used.

1 Like
4

Linking out to What if we did LTSs? as it covers a lot of different angles to consider.

Some thoughts in particular I want to highlight that tie into this specific proposal

  • With people "stagnating" on 2-7 year old versions of Rust, doing discrete upgrades, how do we ensure there is a feedback loop if these people are broken by a new release?
  • Looking over our lists of prior art, this proposal is us going from nothing to one of the longest support cycles, only seen elsewhere by commercial entities. This seems a bit aggressive for us starting out
  • We would need to consider ecosystem preparation that can help with this (2-month release cycles so we have predictable calendar dates, easing long term support with cfg_rust_version, etc)
8 Likes
5

A problem with LTS releases is that people expect to be also able to use newer traits quite often. For some unfathomable reason they expect to be able to mix and match, and are scared of upgrading the compiler but not their crate dependencies. This will introduce a slowing down desire on the whole ecosystem thus, and additional maintainer expectations.

Yet there is nothing is stated in the proposal on who is going to do the work, it is unreasonable to expect unpaid volunteers and hobbyist to do the work for lazy corporations. And even if the rust compiler itself gets funding for LTS support, what about the hundreds of crates so popular they are essentially a requirement for many projects (serde, tokio, etc depending on the problem domain)?

I think a better approach would be if a company that cares about this offers this as a product. Similar to what Ferrocene is already doing for safety certification.

(Also LTS is a sham, any bug fix you backport can also be a breaking change for another customer.)

4 Likes
6

Just for clarity: we also offer LTS for non-safety versions, so this offer already exists. I think it's a different beast though. I have a longer post incoming.

8 Likes
7

Update to pre-RFC: added a subsection to list links to prior discussion of potential LTS for Rust. I welcome additional links to include; I don't remember where to find everything.

At least in theory, the Rust Project could sell access to long term support through the Rust Foundation. In order to provide any real support contract, that would be required. That funding would then be managed by the Foundation in support of the Project initiatives.

Document everything. If it's a critical security fix, LTS customers should be willing to adopt the fix. We just need to provide the why and the how and the things that they may need to pay extra attention to in the update, and then we've filled our commitment to LTS.

Anything more would be the domain of an ad-hoc support contract, and outside of the scope of this RFC.

The ones I'm aware of only require a defined date for end of support, such that it's fully inarguably objective whether someone is in conformance with the requirement or not. So the stable toolchain could meet that requirement if we say we promise support until at least 2031 and then every so often make an announcement that we're very proud to announce that we're going to continue supporting Rust 1 and update that EoL date to stay decently far in the future.

It's primarily about publicly writing down commitments.

However, such requirements often come alongside requirements to not change anything without good, documented reason. So anything beyond "minor fixes and performance improvements" (ie feature updates) requires extra justification that customers that want LTS don't want to have to keep doing just to stay in support.

FWIW I'm attempting to hedge against this with the guidance on when to use LTS. This isn't a case of "if you're in production you should be using LTS," because stable is more than good enough for that. LTS should only be used for projects only receiving reactive maintenance for critical security fixes. Thus they shouldn't have any reason to be updating their library dependencies other than critical security fixes in said libraries.

Which some libraries might not want to offer LTS style guarantees for old versions. But "backport security fixes to older MSRV versions" is a lesser ask than "keep development HEAD on an older MSRV," at least.

Ideally, some sort of (paid?) arrangement where their code can be tested by Crater runs.

In the pre-RFC stage, I'm trying to be reasonably conservative but still on the "wishlist item" stage; I personally hope by expressing this as an official desire of the Project, companies might be willing to step up (e.g. through the Rust Commercial Network) and directly support (with funding) the initiative.

This is explicitly my own opinion, not that of my employer.

LTS is being introduced as a potential RCN initiative on Monday. If adopted, that means funding. But from what I've personally gathered, it's more difficult for companies to justify providing LTS for Rust on their own than doing so on behalf of the Project.

8

Replying as MD from Ferrous Systems, but also as an ex-Rust member that was in multiple previous LTS discussions.

First, the Ferrous Systems/Ferrocene bit: an upstream LTS is a very different beast from the LTS we offer (arbitrarily long, on arbitrary targets, even arbitrarily modified compilers if absolutely needed, by the wish of the customer). For us, it's mostly important that both sides have clearly stated “what's supported” policies, but that ball lies half in our court. So from our perspective, we welcome an initiative in Rust project and will actively help shepherding this RFC.

Some people integrate and ship upstream without intermediary and this is a legitimate use case. I think it would really help them if such a broad support is somewhat in upstream. It’s a much more one-sided relationship: Rust project informs and communicates, it needs to select what it fixes for all downstream consumers.

From my perspective, the first thing an LTS should do is low bar: identify and inform whether the release is affected by a grave issue and with a potential mitigation. This has an interesting insight: Rust doesn’t have an information channel for this. For every informed issue, one can consider to backport and rerelease. This bar for is relatively high - any change and backport can also introduce new bugs, so it should be carefully done.

The second thing is scope: cargo for example has ties to a web service. Is cargo part of the LTS? Does crates.io also support the time frame? Which platforms are under LTS? Just x86 and arm? Is the llvm-tools component part of LTS? What about rustup, is the LTS branch available there and what’s the impact to the tool?

There's a lot of detailed questions, but all hinges on “who works through them and does it in the end?”. This is where most past discussions stopped from my experience. LTS is fundamentally possible, but it needs people with experience and desire to do it.

Just to be open about that: we have knowledge (infrastructure and tooling-wise) to make such a thing fly upstream and would be happy to talk.

5 Likes
9

This. I think if there's an LTS, it should be something not offered by the project, rather by (say) the foundation. (Or by Ferris, or whomever. Could also do it like training, with stamps from the Rust foundation to various vendors offering different kinds of LTSs.)

The foundation can then charge whatever cost is appropriate for access to the LTS binaries. And that can include things like multiple durations of LTS support, at difference price levels, as needed by market forces.

4 Likes
10

IMO the source code for the LTS branches and (to a lesser extent) the binaries shouldn't be behind a paywall, since that makes it much harder for open-source volenteer-run projects like Debian that (I'm guessing) want to ship the LTS version since they're essentially a LTS distribution in that they stay on the same major-minor version for years.

11

Just so we're clear, LTS only has security fixes in the compiler and tooling, based on the current threat model (for example, excluding malicious code).

Does this mean no fixes for soundness issues, miscompiles, or similar, even if they would introduce security issues in the software being compiled with LTS?

12

I dont think that is something to be encouraged. Because then we are right back to additional pressure for having an older MSRV. And most libraries are run by unpaid volunteers, and I know for a fact I dont want the additional workload of dealing with old stable branches and old compilers for a project that I'm doing as a fun hobby.

It is bad enough that with enterprise users, but they at least could throw money at the problem. Debian don't have that ability for the most part. So it will just be a support nightmare.

2 Likes
13

The way I see it, Rust is Libre software, so LTS versions should be public too, regardless of how much we discourage people from using it. I strongly want to avoid any paywalls for the source code, and would prefer binaries to be public as well.

My contributions to Rust are not so the Rust project can make effectively proprietary paid software.

14

This is very much my position too, also for other reasons: a 1:1 relationship for money implies liability and team inflexibility.

If someone wants that: there's businesses for that specific use case.

For projects like Debian, LTS has the advantage of having and upstream agreed LTS version. The other option is that every downstream just takes whatever they want. So you end up Debian LTS being 1.98, RedHat LTS being 1.95... this is horrible. Also, that means that distro maintainers can freely help out upstream to make it happen.

It is still up to library authors if they want to support an LTS or not. No harm done and totally their choice.This is not that dissimilar to browser LTS - many addon authors don't support it, but for some, it's a really useful thing.

An upstream LTS is "niche but broad, no liability", while a downstream compiler service is very much whatever the customer wants, so niche in a niche. I also don't want the Rust Foundation to take up a position in any liability chain (this is, for clarity, a position I hold as one of the initial signatories of the Foundation and as a core team representative back then). The Rust Foundation needs to be a stable guarantor for the Rust project, liability risks that.

BTW, you reasoning is precisely why Ferrocene has a "upstream as much as it's useful to upstream" policy.

I know this whole thing kind of goes against the grain on how the Rust project produces software and how the community works, but this is also an effect of the Rust communities becoming broader and broader.

2 Likes
15

I think it's fair to say the rust project is somewhat chronically underfunded as it is. I can't see how piling more work and responsibility on to the project without funding it is going to lead to good outcomes. Even with "no liability" there will be an expectation and pressure that's legally distinct from liability but not practically different for maintainers.

4 Likes
16

Even if the source is available, what could we do to encourage companies who want it to pay for it? Tyr maintenance burden is going to be significant, and we have seen time and again that companies often dont want to pay for things if they can get sway with it (e.g. openssl until heartbleed, all the small companies that felt they had to relicense away from open source, ...)

Perhaps the code could be available but binaries would cost money to access (Debian want to build their own anyway). Perhaps you need to pay for the rubber stamping and paperwork to show that this is indeed supported (I think this is what Ferrocense does?)

1 Like
17

I do think we need to be careful of this. If the Project does an LTS, we'll have to audit all dependencies to make sure they have a combatible policy.

However, this may not need to be a huge burden, especially a discrete, rather than continuous support policy. I effectively have a reactive LTS for clap where the burden for backporting is on the community. My only job is just making the branch when needed and reviewing. This strikes a good balance for the burden being low. The main downside compared to supporting old versions on main is there is no way to audit for this kind of policy besiders reading READMEs. In fact, having main support LTS may be irrelevant because that could represent too much risk to upgrade to.

1 Like
18

Crates can support LTS in two ways:

  1. Keep the latest version of the crate backwards-compatible with the LTS Rust version.

  2. Support only recent Rust in the latest version, but patch an old version of the crate if necessary.

To me as a maintainer, the second option is unappealing. It requires testing and actively making releases for old versions, that I wouldn't do otherwise. This is where your choice of having LTS demands extra work from me.

The first option doesn't require extra work directly, and if a crate doesn't need latest-greatest Rust features, it's no effort to support. However, it may be difficult to do in practice, because it requires all dependencies to support LTS too. Once deps move on, it creates a tension of keeping deps on older versions, missing out on deps' bugfixes, testing with minimal versions, etc.

So I think for LTS to work and not annoy crate maintainers, Rust needs to have features that make supporting older Rust versions easier.

Quite often crates require newer Rust versions for a trivial reason, like using a new libstd method. A crate using array_chunks doesn't really demand a whole new compiler with a whole new LLVM version. It's just a convenient 1-liner.

So I think some kind of back-compat polyfill would be very helpful in maintaining LTS-compatible ecosystem. I could live with an extra use polyfill::prelude::* in my files if that meant I can use Rust 1.100 libstd methods while keeping Rust 1.85 compat.

2 Likes
19

Another issue I just thought of. On several occasions we had to drop targets in tier or bump the minimum required version of an OS whenever Github Actions stops providing us an easy way to test it. With an LTS we simultaneously wouldn't be allowed to the drop target tier or bump the minimum required version, while also being unable to test it as required for tier 1. So when Github Actions drops support for a target we effectively wouldn't be able to make new releases anymore without breaking the LTS promise or force the infra team to do a lot of work to get a test runner for it again somehow.

2 Likes
20

A polyfill crate exists, but hasn't been updated since 1.6x. We can ask @jhpratt if that was due to workload, lack of use, lack of need or something else.

1 Like