{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiectu4xcc374cjmblyw4ghrux26hfl2oqq67idd7b6peiv37qra4a",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3miswctnjnoz2"
  },
  "path": "/t/why-is-rustc-bootstrap-so-actively-discouraged/24123#post_16",
  "publishedAt": "2026-04-05T17:45:30.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "[2]",
    "↩︎"
  ],
  "textContent": "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.\n\n1.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.\n\nIn 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.\n\n<aside>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.)</aside>\n\n* * *\n\n  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). ↩︎\n\n  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). ↩︎\n\n\n",
  "title": "Why is `RUSTC_BOOTSTRAP` so actively discouraged?"
}