- Feature Name: lts
- Start Date: 2018-06-21
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)
Add an additional release channel for long term releases.
Rust's current release model has, overall, worked very well for us. We maintain a strong degree of backwards compatibility despite producing a new stable release very frequently. Relative to many other languages, it is very easy to upgrade between Rust stable releases.
However, for various institutional reasons, many users do not find it convenient and desirable to upgrade with the frequency that Rust releases. So far, they have been left on their own to figure out when to actually upgrade, creating a situation of uncertainty and disparity. Moreover, because there are no norms around when an older stable stops being "supported," libraries authors experience a similar level of uncertainty around which versions of the compiler their library should be compatible with.
We solve this problem by adding long-term support ("LTS") release channels, providing explicit support for releases beyond the latest stable.
In addition to stable, beta, and nightly, we will add two additional
release tracs:
lts: The most recent LTS release.lts-prior: The second most recent LTS release.
Every fourth stable/beta release, we will perform a release on both the lts
and lts-prior channels. The previous stable release will be the basis for
the new lts release, and the previous lts release will move to the
lts-prior release. This is analogous to the way that the previous beta
becomes the new stable.
To keep it as easy as possible to remember which releases are lts release, we will begin the lts schedule so that the point version of the LTS release is always divisible by four. Depending on implementation schedule, that means that the first LTS release will probably be 1.28 or 1.32, release concurrently with either 1.29 or 1.33.
All three of the stable release channels - stable, lts, and lts-prior - will receive the same level of support. We will host documentation for all three channels and provide equivalent levels of patch release support - that is, if a bug justifying a patch exists in any of these channels, we will release a patch for that channel, just as we do today for stable. However, lts releases are less likely to receive patch releases in practice, since these bugs are most often found in the first six weeks after a stable release.
As a result of this, a stable release which is a candidate for the lts channel (that is, its minor version is a multiple of four) will be supported across all three channels for the following nine release cycles, a period of 54 weeks or just over a year.
Today, library authors fall into three general camps:
- Their library compiles on the nightly channel.
- Their library compiles on the stable channel.
- Their library compiles on any release more recent than an arbitrary old
release, which is different for each library (for example,
failurecompiles on 1.18.0, whereasserdecompiles on 1.13.0).
Frequently, whichever level of support they offer, they guarantee it by testing their code on that channel or release using CI.
The Rust project recommends that library authors interested in providing support for users on versions older than the latest stable, instead of focusing on supporting particular versions, focus on supporting particular release channels. That is, a library may guarantee that it will compile on any of the stable release channels, determining how old the version of Rust their users can be on with a guarantee of compatibility.
We recommend that libraries consider dropping support for a release channel to be a breaking change, but that dropping support for any particular version of Rust to be a non-breaking change.
If a library does not support a particular release channel, effectively all of the libraries that depend on it also do not support that channel. For this reason, we strongly recommend that so-called "core libraries" - those on which many other libraries depend - adopt a practice of supporting all three stable release channels. Examples of core libraries include libc and serde.
For libraries that do not believe they are "core libraries," we make no particular recommendation about which channels to support. There is always a trade off between providing the best API for users on stable as soon as possible vs supporting users who choose to stay on older versions of Rust, and each library should make a judgment call regarding the trade off in their particular circumstances.
Current policy is that the core team decides if a bugfix justifies a patch release to the stable channel. This policy will remain the same for patches to the lts and lts-prior channels.
This increases the maintenance burden on the release and infrastructure teams by adding two additional release channels.
This also muddies our recommendation that users upgrade to the latest stable, which we have worked hard to make very easy to do. In particular, we should not allow the existence of lts releases to justify reducing our effort to identify and resolve stable-to-stable regressions.
Ultimately, users will continue not to upgrade to the latest stable, and libraries will continue to want to support users on some older versions of Rust. Providing a policy allows a better consensus to be formed around what is supported and what isn't.
There are many ways to decide how to provide LTS support. We have chosen to extend our existing channels mechanism by adding more channels, rather than constructing a parallel LTS mechanism.
The main knobs within that context are in regard to when we choose to make lts releases and how many lts channels we support. Our choice to support two lts channels, released every 4 stable releases, is inspired by the ember project's LTS system.
Many different projects offer an LTS release. Our most direct inspiration was the ember project. The ember project's LTS support is described well by both an ember RFC and an ember blog post:
The main deviation from ember's system is that, instead of providing multiple levels of support for different lengths of time for each lts release (ember provides "critical bugfixes" for 6 release cycles and "security patches" for 10 release cycles), we simplify the system by providing equivalent support among all three stable release channels, having the effect of providing all critical bugfixes and security patches we provide to stable today for 9 release cycles for LTS releases.
None known yet.