• Enabling features via Cargo.toml => bad
• Blanket enablement of preview features => bad
• Preview features in stable => bad (anyone taking bets on what will be the first perma-preview feature)!

There is prior art that wasn’t mentioned that I think is relevant. It’s rather obscure though, so it’s understandable that it was missed. It’s called “The Alpha Version”.

Alright let me explain it a bit, since I expect no one heard of this before. Alpha versions are like pre-beta versions that are not nightly. They are used at the start of a release cycle, but without any stability guarantees. You don’t need a very good reason to pull a feature, like with betas. Just a reason would do.

If everything goes well, the release cycle continues with the new to-be-stabilized features. If it doesn’t, stabilization candidates can be pulled and their inclusion postponed to the next release cycle or beyond.

So instead of immediate Stability Proposals, we can have Alpha Inclusion Proposals for the V+1 release cycle, at the start of the V release cycle. Accepting/Rejecting proposals happens at the start of the V+1 cycle. A Stabilize/Postpone decision is made before the first beta. The release cycle can be extended from 6 to 8 weeks if needed so people have enough time to play with alphas.

So instead of nightly => stable (beta) => stable? (stable).

We can have nightly => stable candidate (alpha) => stable? (beta) => stable? (stable)

Pretty novel stuff, I know. This way, people can test stabilization candidates alone in a non-nightly setting, and report feedback. Lack of enough feedback may be used as a “good enough” reason to postpone stabilization!

Here you go, preview features in a release, but not a stable release. And no possibility (ok, less possibility) of previewise-and-forget and perma-preview stuckness for some low-visibility features.