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.
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.
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.
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: Issues · rust-lang/rust · GitHub 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.
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.
