Allow unstable features on beta?

[DanielKeep]

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!”

[Gankro]

What if, for a given release, the core team can “promote” certain feature gates. This allows them to be used in beta

This is exactly what stabilization does for a train.

[logician]

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.

[DanielKeep]

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.

[huon]

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.

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.

[huon]

does @rust-lang/libs not work here or am I Doing It Wrong?

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

[logician]

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.

[aturon]

I believe we have a problem that unstable features are not used by enough users to determine if they are good enough to stabilise.

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.

[brson]

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.

[seanmonstar]

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.

[steveklabnik]

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

[nrc]

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.

[withoutboats]

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.

[skade]

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.

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

[steveklabnik]

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.

[skade]

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.

[withoutboats]

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.

[Gankro]

@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!

[aturon]

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

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.

[nrc]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.