Github RFC: Preview for Unstable Features by jonhoo · Pull Request #3120 · rust-...

It's not clear to me why people can't use Stable to develop and then do a particular build trial with Nightly. This seems like the simplest solution since it doesn't even take an RFC.

A build run with nightly doesn't really provide much supporting evidence for a feature like stripping binaries of debug symbols or a Cargo change like patch-in-config that's meant to improve developer experience. Just because everything still builds doesn't mean the feature works well, as it may well not be tested by a build at all. It needs to be deployed and used, possibly for a week or more, to gather evidence.

It's not clear to me why the opt-in-to-preview can't be done with Beta getting the opt-in. The RFC only seems to consider Beta in the context of allowing every feature ever. Since allowing every feature ever is obviously bad, that part feels like a strawman.

I'm not sure exactly what you're proposing here, so I'll try to tackle both my interpretations:

1. Beta should opt in to all preview features by default.

This would mean that users cannot test only a subset of preview features, which opens up more risk as more unstable features are enabled. Furthermore, it makes beta different enough from stable that users may be hesitant to test on stable as it also exhibits behaviors that won't land in the resulting stable. Or, phrased differently, the fact that something works on beta no longer means that it will work on the resulting stable, which I think is a property we want to preserve.

1. Preview features should only be possible to opt into on beta.

This isn't a bad idea, and is one that's been proposed before, and wasn't outright discarded at the time. I think the biggest reason to not make it beta-only is that beta isn't as stable as stable, and is thus riskier to adopt (and thus less likely to be adopted). Concretely:

As far as I know, Beta is about as bug free as Stable because stuff doesn't generally hit Beta in the first place until it's ready for stabilization.

This is only kind of true. When a new beta is cut, it is exactly as (un)stable as the nightly it was cut from. There's no difference between the two. Then, over time as the beta receives backports, it matures and becomes more stable, until six weeks later when it is actually ready to become the next stable release.

It's not clear to me what would prevent people from using a preview feature in 1.60 and then refusing to update to 1.61 if the preview ended without acceptance.

They wouldn't get new features and bug fixes. This would be the same as pinning an old nightly. Of course, you're right that we generally want the barrier to staying with the latest release at all times to be as low as possible, otherwise the ecosystem ends up stagnating, which is exactly why I propose that preview features be of a very specific kind. Specifically, those that are only likely to be used at the "leaves" of the dependency graph. Pinning the compiler at the leaves is much less problematic than a crate in the "middle" requiring a particular stable version, since there aren't any dependencies (and thus chunks of the ecosystem) that are also held back. This property, in turn, adds pressure to keeping with the latest stable — as the ecosystem above such a pinned leaf crate evolves, and adopts features from newer stable releases, the leaf crate must either drop the pin (and the preview feature), or start pinning all their dependencies as well. And the latter is an option that I think it's fine to let users have — users should have the option to stay in the past if they really want to.

It's unclear what happens when a preview feature is accepted. Since updates ride from Nightly to Beta to Stable, if something is accepted for stabilization, it should ride to Beta then Stable, so does it exist as a preview in 1.60, then not at all in 1.61, and then suddenly exists again in 1.62? Likely it would just exist as a preview for 1.61 as well, but I'd like that written down somewhere.

Right, this is why the RFC suggests that if a preview feature is stabilized, its preview period should be extended to the stable release in which it will land. That way, there won't be any gaps.

Saying that a preview is available "usually a bit longer than one release cycle" seems very strange to me, since Stable either has or does not have the preview. Are you suggesting that we'd alter the 1.60 Stable release 7 weeks (or whatever duration) after it is first released and suddenly people would be downloading a different binary than they did yesterday? Because I sure don't like that idea.

Ah, sorry, no, that's not quite what I meant. The intention wasn't to imply that the stable release would change mid-way through, but rather that the preview window should align with some release after the next, which ends up being "a bit longer than one release cycle" (1.5 on average).