Stabilization is the way that new features are added to Rust. Unlike many languages, where when stuff is added, it goes in the next release, Rust has a multi-stage process so that we can try out features before they're slated to be included in stable Rust.
Small features, especially new library APIs, can be added by just sending in a pull request. Larger features go through the RFC process, so that there can be some consensus around the design before they're implemented. If an RFC is accepted, an implementation can be sent in via PR. Whenever a new feature is added, it goes behind a "feature gate", that is, a special attribute, #![feature], that lets you opt into giving that feature a try.
Every (okay sometimes not every but almost every) night, a nightly build of Rust is made. Nightly builds are used for testing, and so, you can opt into new, unstable features using the #![feature] attribute. Users then give these features a whirl, report bugs, and comment on how the API or feature is used in the real world.
Every six weeks, a nightly is turned into a "beta" release. Betas are like release candidates, and so they don't allow you to use #![feature], and so, don't let you use experimental features. After six weeks, a new nightly becomes beta, and the beta release becomes a new "stable" release. This is what most people mean when they talk about Rust, and what most Rust users use. Stable Rust also doesn't let you use #![feature], as those features aren't stable.
Anyway, after a time (that's at least one whole release cycle), if a feature is good, the team discusses if it should be made stable. If they decide yes, then the #![feature] requirement is removed, and the feature will "ride the trains" to an eventual stable release. If they decide no, it will be deprecated and eventually removed.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
