From 8992a34e15d159b06794aa6bde3dc8d3f40f0c3a Mon Sep 17 00:00:00 2001 From: Without Boats Date: Thu, 21 Jun 2018 15:14:03 -0700 Subject: [PATCH] LTS RFC --- text/0000-lts.md | 164 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 164 insertions(+) create mode 100644 text/0000-lts.md diff --git a/text/0000-lts.md b/text/0000-lts.md new file mode 100644 index 00000000000..5f5fa5210cb --- /dev/null +++ b/text/0000-lts.md @@ -0,0 +1,164 @@ +- Feature Name: lts +- Start Date: 2018-06-21 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary +[summary]: #summary + +Add an additional release channel for long term releases. + +# Motivation +[motivation]: #motivation + +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. + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +## Two new channels: lts and lts-prior + +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. + +## Level of support from the Rust project + +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. + +## Recommendations for library authors + +Today, library authors fall into three general camps: + +1. Their library compiles on the nightly channel. +2. Their library compiles on the stable channel. +3. Their library compiles on any release more recent than an arbitrary old +release, which is different for each library (for example, `failure` compiles +on 1.18.0, whereas `serde` compiles 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. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +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. + +# Drawbacks +[drawbacks]: #drawbacks + +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. + +# Rationale and alternatives +[alternatives]: #alternatives + +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. + +# Prior art +[prior-art]: #prior-art + +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: + +* [RFC 56: Refining the Release Process][ember-rfc-56] +* [Announcing Ember's first LTS][embers-first-lts] + +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. + +# Unresolved questions +[unresolved]: #unresolved-questions + +None known yet. + +[embers-first-lts]: https://emberjs.com/blog/2016/02/25/announcing-embers-first-lts.html +[ember-rfc-56]: https://github.com/emberjs/rfcs/blob/97a92311646624996feba45226f82059858c14f3/text/0056-improved-release-cycle.md