# Why is \`RUSTC\_BOOTSTRAP\` so actively discouraged? **URL:** \ **Category:** Uncategorized\ **Created:** [April 1, 2026, 12:24pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123 "2026-04-01T12:24:19Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [April 1, 2026, 12:24pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/1 "2026-04-01T12:24:19Z")
My thought process is as follows: 1. Many people with more experience than me have thought about this more than I have, so I'm probably missing something ... 2. Rust has very strict and reliable stability guarantees for _very_ good reasons. This does, however, mean that it can take a _very_ long time for _very_ useful features to become fully stabilised. For example `!` has been ongoing since 2016; `try_v2` since 2021; `assert_matches` was in progress from 2021 until 2026. It's understandable that true stabilisation takes years for big complex topics & changes - this is _in no way a complaint_. 3. As a developer I have three options: 1. don't use new features which would be really helpful and wait a few years. 2. use nightly 3. use stable with `RUSTC_BOOTSTRAP` Why I personally tend towards choosing option 3: - I don't want to use nightly as I don't want the instability of daily changes and the risk of breakage at any time. - I can trust that stable will not _accidentally_ break something given the wonderful nightly-beta-stable release process that's in place. That means my only risk is of a deliberate breaking change in an unstable feature I've chosen to use. That's a risk I can better estimate and weigh against the value of using that feature. - I can set up automation to test my crate with each new release and take action on failure (although to my knowledge I have no way of enforcing a _maximum_ supported rust version). - Running automated checks daily is a much bigger use of resources, both natural and personal. I can plan better around a quick check every 6 weeks. - I'm effectively forced to have `RUSTC_BOOTSTRAP` set on my local machine while coding if I want to have rust-analyzer support for testing and linting without huge delays every time I run a test. See: [Issue #17149 · rust-lang/rust-analyzer](https://github.com/rust-lang/rust-analyzer/issues/17149) To my mind that means I get much more limited instability at zero cost vs nightly _and_ I can choose to opt in to a feature where I believe it is worth the cost of instability in _that specific feature_ **So why is this approach so actively discouraged?** The last discussions I can find are from 2021 [here](https://internals.rust-lang.org/t/mechanism-for-beta-testing-unstable-features/14280/21) & [here](https://internals.rust-lang.org/t/the-case-for-a-new-relese-channel-testing/14412/37); they are focussed on slightly different use cases and revolve around making additional changes to the language while taking "`RUSTC_BOOTSTRAP` is bad" as a given. ---
**Author:** ![sfackler](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/sfackler/32/9_2.png) [@sfackler](https://internals.rust-lang.org/u/sfackler)\ **Post date:** [April 1, 2026, 12:34pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/2 "2026-04-01T12:34:48Z")
> [@MusicalNinjaDad](#): > > I don't want to use nightly as I don't want the instability of daily changes and the risk of breakage at any time. You can pin to specific nightlies with rustup. ---
**Author:** ![bjorn3](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bjorn3/32/2736_2.png) [@bjorn3](https://internals.rust-lang.org/u/bjorn3)\ **Post date:** [April 1, 2026, 12:44pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/3 "2026-04-01T12:44:32Z")
For a library `RUSTC_BOOTSTRAP` is a really bad idea. If effectively forces all your consumers to risk being broken with any new rust release. Builds of Firefox broke once because one of their dependencies used `RUSTC_BOOTSTRAP` internally. After that incident Cargo got changed to not allow individual crates to opt in to `RUSTC_BOOTSTRAP` and instead force the person invoking cargo to pass it and thereby acknowledge that the project may break with rustc updated. Also if some library deep down uses `RUSTC_BOOTSTRAP` then it may be very hard to ensure this library gets updated. The library may not do a timely release (for example because it is not actively maintained) or it may do a new release, but the new release is not semver compatible with the version that your project uses. In both cases you are effectively forced to vendor and patch the library. Also the library update may (have to) break compatibility with the MSRV of the project. And finally if the library only updates for breaking changes to unstable features whenever a new stable version gets released, that makes it effectively unusable on nightly and beta, preventing your users from finding bugs in rustc before it is already too late. For an end project, these risks are less bad and there are some major projects that use it (Rust for Linux (RfL), Chromium, ...), but still we prefer if people don't do this. In the case of RfL we are actively collaborating on unstable features they need to get them to a stabilizeable state. And for RfL we have a CI job on the rust side that allows us to notify the RfL maintainers about the impending breaking change such that they can adapt to the changes quickly. ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [April 1, 2026, 1:11pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/4 "2026-04-01T13:11:45Z")
I fully understand and agree with the sentiment that any use of unstable features in a library should be very carefully considered and brings significant additional responsibility to the author and risk to the user. (That's option 1 on the list - "don't use the feature") What I don't get is why stable + bootstrap is "worse than nightly" and not "better than nightly" in this regard. Maybe it's a communication thing and the idea is to avoid any hint of "using unstable features is fine and safe and stable" (?) so as not to end up with a large part of the ecosystem full of crates which overheard the nuanced "carefully weigh the costs and risks when deciding". "Nightly only" with a big yellow warning is scary (deliberately, and for good reason). > [@bjorn3](#): > > After that incident Cargo got changed to not allow individual crates to opt in to `RUSTC_BOOTSTRAP` and instead force the person invoking cargo to pass it and thereby acknowledge that the project may break with rustc updated. Yes, but why does that argument not hold just the same for nightly (also not available on a per-crate basis) where the breakage could happen every 24 hours, not every 6 weeks? > [@bjorn3](#): > > The library may not do a timely release (for example because it is not actively maintained) or it may do a new release, but the new release is not semver compatible with the version that your project uses > > ... > > Also the library update may (have to) break compatibility with the MSRV of the project. All valid risks whether the library uses stable, nightly or bootstrap. Although the delineation is admittedly very clear between stable (if the library author ignores this forever, rust authors guarantee it won't break between editions) and nightly (you need to trust the library author to keep on top of this constantly). > [@bjorn3](#): > > if the library only updates for breaking changes to unstable features whenever a new stable version gets released, that makes it effectively unusable on nightly and beta, preventing your users from finding bugs in rustc before it is already too late. That I don't understand. I _can_ `cargo +nightly/+beta build/test` such a library or anything that uses it. I have the risk that something broke in the specific enabled feature in the last few weeks which the author hasn't seen or reacted to yet, but if I'm actively choosing nightly or beta then I am deliberately buying in to higher risk for reasons which make sense to me. ---
**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\ **Post date:** [April 1, 2026, 1:48pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/5 "2026-04-01T13:48:21Z")
> [@MusicalNinjaDad](#): > > That means my only risk is of a deliberate breaking change in an unstable feature I've chosen to use Or a bug in an unstable feature, which will stick around for a full stable cycle even if it's been fixed in nightly, because people are not necessarily paying attention to whether a given unstable feature remains functional in a stable release. Any given nightly feature can be broken in any given nightly, and fixed in a subsequent nightly; if that _happens_ to be the point at which beta branches from, the feature will stay broken, and there's no particular reason to backport a fix for it. ---
**Author:** ![RalfJung](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ralfjung/32/2415_2.png) [@RalfJung](https://internals.rust-lang.org/u/RalfJung)\ **Post date:** [April 1, 2026, 2:13pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/6 "2026-04-01T14:13:08Z")
> [@MusicalNinjaDad](#): > > Yes, but why does that argument not hold just the same for nightly (also not available on a per-crate basis) where the breakage could happen every 24 hours, not every 6 weeks? First of all, it is your choice how often you update the nightly version you use or support for your project. Nobody forces you to update every 24 hours. Also, if you use stable, then things are very unlikely to break every 6 weeks. We spend a lot of effort on that. But if any of your dependencies uses unstable features, the risk of breakage increases dramatically. Therefore it is very important that you as application developer know whether any _transitive_ dependency needs unstable features. But anyway that hole in the Rust stability story has been fixed so this is not a concern any more. * * * To answer the original question -- there is a non-trivial social contract around RUSTC\_BOOTSTRAP. Using it responsibly comes with a bunch of obligations to the party that enables this flag. If it gets overused, that is very likely to do enormous damage to the Rust ecosystem. We _need_ the freedom to iterate on unstable features, including breaking changes, without the overhead of deprecation periods and future-compatibility cycles. If a sufficiently large part of the ecosystem breaks when we do that, we effectively lose that freedom, which is very bad news for Rust language development. We strongly discourage its use because we want to avoid that damage. So, why should you not use RUSTC\_BOOTSTRAP? For the same reason that you shouldn't let your cows overfeed on the [common pasture](https://en.wikipedia.org/wiki/Tragedy_of_the_commons). ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [April 1, 2026, 3:17pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/7 "2026-04-01T15:17:17Z")
Thanks for the clear and honest explanation. I'm glad I hadn't missed anything technical and had simply mis-considered the social impact. Regarding how often I update my nightly - that's less of my concern than how often my downstream users will (and over that I have no control, so must assume that every nightly version could be used immediately) While likely rare occurrences, I see that more acceptance of RUSTC\_BOOTSTRAP would lead to pressure on maintainers to backport breakages into beta as per [josh's comment above](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/5) **Most importantly:** I see the risk to the ecosystem if RUSTC\_BOOTSTRAP started down the slippery slope of not-shunned-\>accepted-\>normalised as it could easily become very widespread and feel a lot safer than "⚠ nightly", leading to many broken crates. I will certainly ensure I document my work with this in mind (I'll be updating the readme/crate-level docs and publishing a hotfix release to at least one crate today [update: done, all references to bootstrap removed for try\_v2 & currently #200 in the queue at docs.rs]). Following on from this, I'm wondering what the right wording would be for: > ### Stability > > This crate makes use of unstable features x,y,z (with links), as such it requires users to set `RUSTC_BOOTSTRAP=1`on stable, or use nightly. > > The crate is tested with `RUSTC_BOOTSTRAP = 1` on each update of stable (every 6 weeks). In the unlikely case of breakage, a hotfix version update restricting the supported toolchain will be released immediately and a fix will follow as soon as possible afterwards. > > As such you can expect the crate to work as long as features x,y,z are not broken in the current stable/nightly build. maybe something like: > ### Stability > > This crate makes use of unstable features x,y,z (with links). Great care is taken to ensure continued stability of the crate and the use of unstable functionality is strictly limited. > > Automated tests are run every 3 weeks, against the version of nightly which is promoted to beta and again when a new stable is release. In the unlikely case of breakage, a hotfix version update restricting the supported toolchain will be released immediately and a fix will follow as soon as possible afterwards. > > In case of issues with a specific nightly release outside these checkpoints, please raise an issue (link) including details of the toolchain used. Is there already something out there in common use that I've just never noticed, analog the standard inclusion of a "Safety" section for any usage of unsafe, and the function-level annotations for nightly APIs in docs? ---
**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\ **Post date:** [April 1, 2026, 3:24pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/8 "2026-04-01T15:24:49Z")
FWIW, I think the issue mentioned in rust-analyzer is the kind of thing that does harm via propagating RUSTC\_BOOTSTRAP. rust-analyzer apparently said "there's an unstable JSON output that we want, so we're going to set RUSTC\_BOOTSTRAP to get it", and then a predictable set of problems ensued. This should never have happened in the first place; stable rust-analyzer should not be using this feature. ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [April 1, 2026, 3:33pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/9 "2026-04-01T15:33:10Z")
yeah, (a bit off topic but a good example of the issues involved) that's an almost impossible tradeoff, every choice is bad: - have poor support of in IDE testing for a major IDE where it is generally expected -\> poor DevEx for the language - make (undocumented) use of RUSTC\_BOOTSTRAP and have users annoyed about why their machine keeps completely rebuilding the project before and after every test run -\> poor DevEx for the language - clearly document the use of RUSTC\_BOOTSTRAP, propagate acceptance and ... see above points made by Ralf -\> poor DevEx for the language ---
**Author:** ![josh](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/josh/32/5934_2.png) [@josh](https://internals.rust-lang.org/u/josh)\ **Post date:** [April 1, 2026, 3:44pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/10 "2026-04-01T15:44:42Z")
Part of the issue is that using RUSTC\_BOOTSTRAP sidesteps the process of "finish and ship a stable feature". ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [April 1, 2026, 3:55pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/11 "2026-04-01T15:55:10Z")
automation can help a lot with this. My standard setup is to have dependabot run daily with auto-approval on all PRs where nothing breaks. This only works because I have meaningful, complete test coverage (that's how I code out of preference). Still, if a downstream dependency makes a breaking change I have to go fix it (one crate in particular does this often for something I care about) and yes, that's often a hassle and very easy to overlook for longer than I feel comfortable with. But at least I can rely on cargo to ensure no-one else gets broken, "just" held back. ---
**Author:** ![Nemo157](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nemo157/32/11585_2.png) [@Nemo157](https://internals.rust-lang.org/u/Nemo157)\ **Post date:** [April 1, 2026, 4:14pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/12 "2026-04-01T16:14:40Z")
> [@MusicalNinjaDad](#): > > I can trust that stable will not _accidentally_ break something given the wonderful nightly-beta-stable release process that's in place. That means my only risk is of a deliberate breaking change in an unstable feature I've chosen to use. That's a risk I can better estimate and weigh against the value of using that feature. This isn't really true for unstable features, they're commonly undertested and have bugs which will reach a stable compiler, and as already mentioned you then need to wait 6+ weeks till the next release to see if it fixes it. Whereas if you were using a pinned nightly you can report the bug and maybe it'll be fixed sooner and you could update your pin. But really the main reason is that _you_ must take all responsibility of anything that breaks if you use `RUSTC_BOOTSTRAP`, if it becomes normalized to use it then people that don't take that responsibility will start using it and complaining when stuff breaks. Increasing the workload on contributors for no real gain. ---
**Author:** ![kpreid](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kpreid/32/8484_2.png) [@kpreid](https://internals.rust-lang.org/u/kpreid)\ **Post date:** [April 1, 2026, 5:58pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/13 "2026-04-01T17:58:49Z")
While it hasn't seen much recent motion, there is an RFC that proposes both breaking down RUSTC\_BOOTSTRAP into finer grained control, and discouraging that replacement feature less: > > > This RFC was in large part drafted in May 2025, shortly after my Rust All Hands …talk, "Futile Feature Gates". There were about 25 people in that room; I want to thank all of them for their feedback during that session, and everyone who reviewed early drafts of this RFC. > > \[Rendered\](https://github.com/jyn514/rfcs/blob/rustc-bootstrap/text/0000-rustc-bootstrap.md) > > > > > \> \[!IMPORTANT\] > \> When responding to RFCs, try to use inline review comments (it is possible to leave an inline review comment for the entire file at the top) instead of direct comments for normal comments and keep normal comments for procedural matters like starting FCPs. > \> > \> This keeps the discussion more organized. ---
**Author:** ![ProgramCrafter](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/programcrafter/32/13494_2.png) [@ProgramCrafter](https://internals.rust-lang.org/u/ProgramCrafter)\ **Post date:** [April 1, 2026, 7:53pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/14 "2026-04-01T19:53:34Z")
> [@MusicalNinjaDad](#): > > the wonderful nightly-beta-stable release process that's in place _Argument from second-order effects:_ Doesn't it depend on bugs of unstable features being reported from the wild? For that, you'd want people trying out the feature as soon as it appears (which is in the nightly). Personally speaking, whenever I try to use a QoL feature in my app and see it is unstable, I just switch to nightly to never come back to stable. ---
**Author:** ![dhm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/dhm/32/4879_2.png) [@dhm](https://internals.rust-lang.org/u/dhm)\ **Post date:** [April 4, 2026, 11:13am UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/15 "2026-04-04T11:13:25Z")
The OP does correctly mention the merits of _versioned nightly_. Indeed, I do think version nightly, assuming it's interpreted as `x.y.z-nightly` in Cargo-Semver parlance (_i.e._, [breaking even when just bumping `z`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a09a58f59341cf4c29e1ff335434eb04)), can be preferable to "dated nightly", barring patches: - version numbers are way more memorable than arbitrary cut-off dates, - especially when cross-referencing with stabilized APIs. 😵‍💫 **So yeah, it would be quite handy to get some form of versioned nightly.** * * * And it just turns out that, for now, since we don't have that in any form, the only way to hackily DIY-polyfill such a thing is through `RUSTC_BOOTSTRAP=1 +stable`. And this is _socially_ problematic, since it has the name `stable` in its name (it sounds like "nightlied `stable`" more than "_versioned_ `nightly`"). I personally, and at work, use this in certain scenarios (whilst being willing to exceptionally use pinned nightly for a hotfix), and to great success, out of the value of versioned nightly as a concept. But it is very important to be aware of the tradeoffs and limitations that come with it. ### TL,DR We'd probably benefit from an official support of versioned nightly so as to supersede this hacky but otherwise currently-legitimate usage of `RUSTC_BOOTSTRAP=1 +stable`. ---
**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\ **Post date:** [April 5, 2026, 5:45pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/16 "2026-04-05T17:45:30Z")
Theoretically this should "just" be a new rustup channel, right? No need to invest extra CI build time. It should be fine if the `--version` reports the same as the nightly build, so when promoting 1.ZX.0-beta, "just" also push that day's nightly build to a new "fortnightly"\[1\] release channel. 1.ZX.0-nightly is thus equivalent to the first nightly for 1.ZY.0. This is one release train off of "grab the nightly from the same date as the named stable," but I think fits the best with the existing version trains, since it would ensure that, modulo beta backports, 1.ZX-nightly ≈ 1.ZX-beta ≈ 1.ZX-stable. In a perfect world with infinite CI build resources, the "versioned nightly" toolchain would be the beta toolchain but built to support unstable features, thus receive beta backports, and could even entirely replace the use of `RUSTC_BOOTSTRAP` for building rustc\[2\]. But that isn't realistic, so just an alias channel _would_ be a relatively cheap nicety. \I typically just pick first-of-the-month nightlies to pin to, unless there's a specific recent nightly with a change I want. (But actually I'm usually on floating nightly since my nightly using projects are usually short lived experiments or only use stable-but-for-X (typically library) features.)\ * * * 1. Fortnightly would be a technically incorrect but cute release channel name. A technically correct but obscure option: sesquimonthly (1½-monthly), sexaweekly (6-weekly), or octantly (⅛-yearly). 2. Though we probably would need to continue supporting some sort of unstable enabling environment variable for IDE usage, like exists for enabling ra-proc-macro-host. IDE plugins are _effectively_ part of the toolchain, able and expected to keep up with nightly churn, and updated at least as often as the toolchain itself, so maybe the best use case of unstable-on-stable after bootstrap… at least if it only effected what the IDE has available and wasn't visible to the built crate (e.g. causing rebuilds). ---
**Author:** ![dhm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/dhm/32/4879_2.png) [@dhm](https://internals.rust-lang.org/u/dhm)\ **Post date:** [April 5, 2026, 7:23pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/17 "2026-04-05T19:23:35Z")
> [@CAD97](#): > > "fortnightly"[^1] release > > [^1]: Fortnightly would be a technically incorrect but cute release channel name. A technically correct but obscure option: sesquimonthly (1½-monthly), sexaweekly (6-weekly), or octantly (⅛-yearly). 😂 love this! 👏 (and I agree with/like your more serious suggestions) ---
**Author:** ![MusicalNinjaDad](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/musicalninjadad/32/11986_2.png) [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)\ **Post date:** [April 7, 2026, 12:38pm UTC](https://internals.rust-lang.org/t/why-is-rustc-bootstrap-so-actively-discouraged/24123/18 "2026-04-07T12:38:51Z")
Thanks. I've thought about that RFC a lot, since you posted, and have finally organised my thoughts well enough to add a comment. Overall, I'm conflicted on this topic, as I see the danger to stability-as-a-feature from having any experimental feature usage on stable. At the same time, I see, and feel, the clear need to have a more stable release channel where opt-in is possible. At least now, my original question is well & truly answered.