Allow unstable features on beta?


#17

To refocus the discussion a bit, I think this is the problem statement:

Others have pointed out other reasons for wanting a more regularly released “unstable Rust,” but as far as I can see, most of them resolve to some variation of “nightly Rust is too inconvenient to use.” I think that’s exactly how it was intended to be. De facto stabilization is a real thing, and the more convenient we make unstable features to use, the more at risk we are for de facto stabilization. If you need to use nightly for feature X but feature X is unstable and nightly is too inconvenient, then, we should try to make feature X usable on stable (even if that means that it takes months, or perhaps in some cases, years). The inconvenience of nightly Rust has utility: it is a good forcing function to stabilize stuff that a lot of people want.

The problem stated by @nrc is directly at odds with that line of thinking though. :frowning: I agree that it’s a real problem. There are many instances where we just really need people to gain experience with a new unstable feature, e.g., the new std::panic module. If we continue to make unstable features inconvenient to use, then we aren’t going to be able to collect the data we’d like, and we risk stabilizing something that has flaws that would have been uncovered with more practice.

I don’t know where I land on this personally. However, I do think it’s valuable to keep the key trade off in mind: risk de facto stabilization or make it harder to collect data on experience with unstable features. If we can come to a consensus on that trade off (which certainly isn’t binary), then it might be easier to figure out the implementation details (like an “unstable release”).


#18

What if, for a given release, the core team can “promote” certain feature gates. This allows them to be used in beta and maybe even stable compilers. The trade-off is that all compilations using those flags print out big, scary warnings explicitly saying “this feature may or may not exist in the next release”. These gates should also be detectable via #[cfg(..)] in some fashion.

If the number of “promoted” gates is kept reasonably low, this can serve as a kind of advertisement. It’s effectively saying “hey, here are some new features we’re thinking about; please try them out, but don’t rely on them sticking around”.

If nothing else, it might be more enticing than the relative Wild West that nightly is: “here’s a big ol’ pile a stuff; some of it might get stabilised, some of it might get removed, who the hell knows, yee-haw!”


#19

This is exactly what stabilization does for a train.


#20

I, too, currently don’t see the point at all to Beta and I’d really like to see something like this implemented so people will have a reason to use it.

What was wrong with the old Stable - Unstable - Experimental - Deprecated system again?

Experimental could be used for most of what we consider unstable APIs today and be only accessible in the nightlies, and then APIs which are on the path to stabilization, or only have a few small hangups in their design, could be moved to Unstable and be accessible in beta.

Basically Unstable would be useful for all the currently unstable APIs which are only marked as such because they’re not battle-tested yet, but which match RFC specification and aren’t likely to change a whole lot before being stabilized. Think of a stability level that says “matches RFC specification; waiting for the dust to settle” without that needing to be added.


#21

But at that point, it’s mostly a done deal, right? I mean, something doesn’t make it to beta unless it’s more or less been nailed down sufficiently well that it’s now just a question of time before it hits stable. I’m thinking of features where things are less certain, and more feedback is needed before stabilising.

Or I might be completely misunderstanding how the core team sees things… in which case, perhaps there does just need to be better advertisement on these things.

“things, things, things”; sorry; just got up. Brain not on yet. :stuck_out_tongue:


#22

In many ways, beta is a final step just to try to ensure bugs don’t hit stable by having six weeks of stability. It is designed to be used for testing/in CI systems, not for regular development, e.g. most travis configurations I see will test on at least nightly, beta and stable (using only nightly for this purpose isn’t great, as it is regularly being changed, possibly introducing new regressions).

I personally don’t think we should invent reasons for people to use beta for development just for the sake of having a reason, especially as the current system ensures that beta is a release candidate for the stable channel: using the same configuration ensures that, e.g., we won’t miss regressions due to some bug in the system managing the feature gating. That said, having layered instability might mean we get more feedback about the less unstable things, although it does weaken the stability story/increase the pressure on things for de facto stabilisation.


#23

Seems to be called @library_subteam here (sorry for the ping, team).


#24

It doesn’t have to be the Beta channel. We could have an additional Unstable or Alpha channel to house unstable APIs while experimental APIs remain on nightlies.


#25

I’m wondering about the context of this belief. Is there some specific evidence you’re thinking about? Some mis-stabilization?

Personally, I feel like the FCP process has helped bring focus to significant nightly features prior to stabilization. Not every issue gets a ton of activity, but the more major APIs definitely do. And much of the time the activity is people chiming in to say they are using the (nightly) feature.


#26

Before promoting features we might be able to do some simple analysis to see how much usage its getting, reach out to those users for feedback, take further steps if nobody seems to be using it.

The beta cycle prior to stabilization does contain the unstable feature, so there’s a six week window where we can tell prospective users to prepare their code and get last minute feedback.


#27

How about on release day, besides the stable release post, a second post regarding the new Beta is written as well. This could highlight any newly stabilized features that people should test out.


#28

We used to announce beta stuff in release notes, but it felt weird, since the next announcement was basically a repeat of the beta announcement from the previous release


#29

So, a lot of these comments have persuaded me it might not be a good idea. However, in answer to a few of the themes:

beta is useful for CIs

It would still be, if you didn’t opt in to any feature flags, then it does the same thing it does now. We could even have a command line flag to ensure this.

beta doesn’t have many users

it might get more if there were a reason to use it. It sounds from some comments here that that might be the case.

we already ride the trains with unstable features when they become stable

This is true, but by that stage we would only un-stabilise in a bad case. Perhaps we could change this policy? We make most new features stable by default after a cycle on nightly unless there is reason not to (i.e., we don’t wait for a good reason to) and we get more trigger happy about de-stabilising stuff before it hits stable if its not up to scratch.

is this really an issue anyway?

(@aturon)

this is probably the most important question. I’m definitely thinking more of language features than libs/API. My worry is more that we aren’t starting the stabilisation for some features, rather than that we’ve mis-stabilised. DST coercions are probably the worst example. Looking at this list: https://github.com/rust-lang/rust/issues?page=1&q=is%3Aissue+is%3Aopen+tracking+label%3AT-lang+label%3AB-unstable most issues have no commens at all, very few have more than one or two.


#30

I think unstable feature discovery could be improved also. I am much more likely to switch to nightly for an std API than for a language feature, because they’re documented in the std docs.


#32

AFAIK, that’s an issue of rustdoc that needs to be ironed out. /cc @steveklabnik?


#33

I have so much work to do documenting stable things that investing time in docs that may not last isn’t really the right use of my time.

At some point this will change, but not right now.


#34

I wasn’t implying that, I just wasn’t sure if my statement was right. I’ll see if I can find some people on 32C3 to hack on that.

<3 for all your work.


#35

I think something relatively easy to do that could help would be if the release notes had a “What’s new in 1.X-nightly” section.


#36

@nrc in the past I suggested autostablization, but the rest of the libs team didn’t like it. See the life and death of an api thread.

I definitely think the lang team should consider deviating from the libs strategy here!


#37

Why? I feel like the strategy with libs has been working quite well.

The list of issues that @nrc pointed to are largely ones that I recently created to exhaustively track every feature flag, just as we do with libs. Many of the flags are obscure, others are tied to larger constellations of features that should probably be stabilized together (e.g., there are several feature flags involved in SIMD support). I don’t see any particular urgency to take action on most of these issues.

For the example of unsizing coercions, I suspect the basic problem is twofold: lack of advertisement of the feature, and the fact that it’s a somewhat niche feature in the first place.

So far, the lang team has yet to go through a full nomination process for the recently-added tracking features, like we do each cycle on the libs team. I think the simplest step to take here is, next cycle, to do a full round of nomination and start tagging some of these issues for FCP in one direction or another. As we’ve found with library APIs, the FCP is a great way of focusing attention and spurring discussion, and – contrary to the presupposition of this thread – many unstable APIs are indeed seeing wide use already.