Allow unstable features on beta?

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:

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.


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

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.

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.

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.

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.

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

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?


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: most issues have no commens at all, very few have more than one or two.

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?

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.

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.

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.

1 Like

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

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.

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