Release channels take 2

This RFC describes changes to the Rust release process, primarily the division of Rust's time-based releases into 'release channels', following the 'release train' model used by e.g. Firefox and Chrome; as well as 'feature staging', which enables the continued development of experimental language features and libraries APIs while providing strong stability guarantees in stable releases.

This revision includes a significant simplification by merging stability attributes with feature gates, which further enables some additional useful features within Cargo related to version detection. One big implication of this change is that stability attributes are no longer suitable for use outside of std (if such a feature is desirable it is intended to be solved by Cargo).
> The major purpose of this is to prevent access entirely to #[unstable] APIs, not to just warn-on-use. [... A]lmost all of the benefits of the stability attributes here are gained through libraries declaring semver-requirement dependencies on one another themselves.

Maybe a better way to put it is this: In my view, this is not extending the existing attributes. It's more like this proposal simply removes the existing attributes, and then reuses some of the names for a very different set of attributes that have only a little functionality in common with the old ones.

It would not be totally crazy, I think, for the old and new versions to coexist without having the same spelling. Of course, maybe it's not considered worthwhile to maintain the current attributes in this way, but I still would be happier if some way of annotating unstable/stable/deprecated remained for third-party libraries.

> I envision the ability to have unstable features in Cargo manifest (note I mean Cargo features, not stability-attribute features).

I'm still a bit confused. For me, the point is that some projects may, for whatever reason, have a significant number of users developing against versions of their libraries with unstable features. Maybe the library is still on version 0.y.z, or maybe they just have popular nightly/alpha/beta builds. In this case, you want to (a) communicate which features are still considered unstable in documentation, and (b) give users an way to automatically check which unstable features they are using. This may even apply to developers preparing releases that want to be sure that they haven't accidentally left in unstable features that they thought were already rejected and removed.

For stable versions, there are similar issues for items in the API that are deprecated (as you mention in the RFC already).

For these uses, I think it's best to be able to annotate the source code directly (especially because that's also where the rustdoc documentation is). Tracking features in the Cargo manifest is useful, but I think that it solves a different set of problems. (Unless I'm still totally misunderstanding your suggestion.)

> [P]ackages published to crates.io will not have any experimental features.

Note that this means that package versions that *have* to have a mix of newly-stable and unstable features (e.g. 0.y.z packages trying to get early adopters to try things out) really have to live mostly outside the crates.io ecosystem, which means that they may not have so much of an advantage over the standard library.