8000 Blog post: Stability as a Deliverable · adevore/blog.rust-lang.org@8876b52 · GitHub
[go: up one dir, main page]
Skip to content

Commit 8876b52

Browse files
aturonaturon
committed
Blog post: Stability as a Deliverable
1 parent 9a3850e commit 8876b52

File tree

1 file changed

+196
-0
lines changed

1 file changed

+196
-0
lines changed

‎_posts/2014-10-30-Stability.md

Lines changed: 196 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,196 @@
1+
---
2+
layout: post
3+
title: "Stability as a Deliverable"
4+
author: Niko Matsakis and Aaron Turon
5+
---
6+
7+
The upcoming Rust 1.0 release means
8+
[a lot](http://blog.rust-lang.org/2014/09/15/Rust-1.0.html), but most
9+
fundamentally it is a commitment to stability, alongside our
10+
long-running commitment to safety.
11+
12+
Starting with 1.0, we will move to
13+
a 6-week release cycle and a menu of release "channels". The stable
14+
release channel will provide pain-free upgrades, and the nightly
15+
channel will give early adopters access to unfinished features as we
16+
work on them.
17+
18+
### Committing to stability
19+
20+
Since the early days of Rust, there have only been two things you
21+
could count on: safety, and change. And sometimes not the first
22+
one. In the process of developing Rust, we've encountered a lot of
23+
dead ends, and so it's been essential to have the freedom to change
24+
the language as needed.
25+
26+
But Rust has matured, and core aspects of the language have been
27+
steady for a long time. The design feels right. And there is a huge
28+
amount of pent up interest in Rust, waiting for 1.0 to ship so that
29+
there is a stable foundation to build on.
30+
31+
It's important to be clear about what we mean by stable. We don't mean
32+
that Rust will stop evolving. We will release new versions of Rust on
33+
a regular, frequent basis, and we hope that people will upgrade just
34+
as regularly. But for that to happen, those upgrades need to be
35+
painless.
36+
37+
To put it simply, our responsibility is to ensure that you never dread
38+
upgrading Rust. If your code compiles on Rust stable 1.0, it should
39+
compile with Rust stable 1.x with a minimum of hassle.
40+
41+
### The plan
42+
43+
We will use a variation of the train model, first introduced in web
44+
browsers and now widely used to provide stability without stagnation:
45+
46+
* New work lands directly in the master branch.
47+
48+
* Each day, the last successful build from master becomes the new nightly release.
49+
50+
* Every six weeks, a beta branch is created from the current state of
51+
master, and the previous beta is promoted to be the new stable
52+
release.
53+
54+
In short, there are three release channels -- nightly, beta, and
55+
stable -- with regular, frequent promotions from one channel to the
56+
next.
57+
58+
New features and new APIs will be flagged as unstable via feature gates
59+
and
60+
[stability attributes](http://doc.rust-lang.org/reference.html#stability),
61+
respectively.
62+
Unstable features and standard library APIs will only be available on
63+
the nightly branch, and only if you explicitly "opt in" to the
64+
instability.
65+
66+
The beta and stable releases, on the other hand, will only include
67+
features and APIs deemed *stable*, which represents a commitment to
68+
avoid breaking code that uses those features or APIs.
69+
70+
### The FAQ
71+
72+
There are a lot of details involved in the above process, and we plan
73+
to publish RFCs laying out the fine points. The rest of this post will
74+
cover some of the most important details and potential worries about
75+
this plan.
76+
77+
#### What features will be stable for 1.0?
78+
79+
We've done an analysis of the current Rust ecosystem to determine the
80+
most used crates and the feature gates they depend on, and used this
81+
data to guide our stabilization plan. The good news is that the vast
82+
majority of what's currently being used will be stable by 1.0:
83+
84+
* There are several features that are nearly finished already: struct
85+
variants, default type parameters, tuple indexing, and slicing syntax.
86+
87+
* There are two key features that need significant more work, but are
88+
crucial for 1.0: unboxed closures and associated types.
89+
90+
* Finally, there are some widely-used features with flaws that cannot
91+
be addressed in the 1.0 timeframe: glob imports, macros, and syntax
92+
extensions. This is where we have to make some tough decisions.
93+
94+
After extensive discussion, we plan to release globs and macros as
95+
stable at 1.0. For globs, we believe we can address problems in a
96+
backwards-compatible way. For macros, we will likely provide an
97+
alternative way to define macros (with better
98+
[hygiene](http://en.wikipedia.org/wiki/Hygienic_macro)) at some later
99+
date, and will incrementally improve the "macro rules" feature until
100+
then. The 1.0 release will stabilize all current macro support,
101+
including import/export.
102+
103+
On the other hand, we *cannot* stabilize syntax extensions, which are
104+
plugins with complete access to compiler internals. Stabilizing it
105+
would effectively forever freeze the internals of the compiler; we
106+
need to design a more deliberate interface between extensions and the
107+
compiler. So syntax extensions will remain behind a feature gate for
108+
1.0.
109+
110+
Many major uses of syntax extensions could be replaced with
111+
traditional code generation, and the Cargo tool will soon be growing
112+
specific support for this use case. We plan to work with library
113+
authors to help them migrate away from syntax extensions prior to
114+
1.0. Because many syntax extensions don't fit this model, we also see
115+
stabilizing syntax extensions as an immediate priority after the 1.0
116+
release.
117+
118+
#### What parts of the standard library will be stable for 1.0?
119+
120+
We have been steadily stabilizing the standard library, and have a
121+
plan for nearly *all* of the modules it provides. The expectation is
122+
that the vast majority of functionality in the standard library will
123+
be stable for 1.0. We have also been migrating more experimental APIs
124+
out of the standard library and into their own crates.
125+
126+
#### What about stability attributes outside of the standard library?
127+
128+
Library authors can continue to use stability attributes as they do
129+
today to mark their own stability promises. These attributes are not
130+
tied into the Rust release channels by default. That is, when you're
131+
compiling on Rust stable, you can only use stable APIs from the
132+
standard library, but you can opt into experimental APIs from other
133+
libraries. The Rust release channels are about making upgrading *Rust
134+
itself* (the compiler and standard library) painless.
135+
136+
Library authors should follow [semver](http://semver.org/); we will
137+
soon publish an RFC defining how library stability attributes and
138+
semver interact.
139+
140+
#### Why not allow opting in to instability in the stable release?
141+
142+
There are three problems with allowing unstable features on the
143+
stable release.
144+
145+
First, as the web has shown numerous times, merely *advertising*
146+
instability doesn't work. Once features are in wide use it is very
147+
hard to change them -- and once features are available at all, it is
148+
very hard to prevent them from being used. Mechanisms like "vendor
149+
prefixes" on the web that were meant to support experimentation
150+
instead led to de facto standardization.
151+
152+
Second, unstable features are by definition work in progress. But the
153+
beta/stable snapshots freeze the feature at scheduled points in time,
154+
while library authors will want to work with the latest version of the
155+
feature.
156+
157+
Finally, we simply *cannot* deliver stability for Rust unless we
158+
enforce it. Our promise is that, if you are using the stable release
159+
of Rust, you will never dread upgrading to the next release. If
160+
libraries could opt in to instability, then we could only keep this
161+
promise if all library authors guaranteed the same thing by supporting
162+
all three release channels simultaneously.
163+
164+
It's not realistic or necessary for the entire ecosystem to flawlessly
165+
deal with these problems. Instead, we will enforce that stable means
166+
stable: the stable channel provides only stable features.
167+
168+
#### Won't this split the ecosystem? Will everyone use nightly at 1.0?
169+
170+
It doesn't split the ecosystem: it creates a subset. Programmers
171+
working with the nightly release channel can freely use libraries that
172+
are designed for the stable channel. There will be pressure to
173+
stabilize important features and APIs, and so the incentives to stay
174+
in the unstable world will shrink over time.
175+
176+
We have carefully planned the 1.0 release so that the bulk of the
177+
existing ecosystem will fit into the "stable" category, and thus
178+
newcomers to Rust will immediately be able to use most libraries on
179+
the stable 1.0 release.
180+
181+
#### What are the stability caveats?
182+
183+
We reserve the right to fix compiler bugs, patch safety holes, and
184+
change type inference in ways that may occasionally require new type
185+
annotations. We do not expect any of these changes to cause
186+
headaches when upgrading Rust.
187+
188+
The library API caveats will be laid out in a forthcoming RFC, but are
189+
similarly designed to minimize upgrade pain in practice.
190+
191+
#### Will Rust and its ecosystem continue their rapid development?
192+
193+
Yes! Because new work can land on master at any time, the train model
194+
doesn't slow down the pace of development or introduce artificial
195+
delays. Rust has always evolved at a rapid pace, with lots of help
196+
from amazing community members, and we expect this will only accelerate.

0 commit comments

Comments
 (0)
0