it does, to some extent, it depends on the tool and the aspect of the tool
this also has negative effects: a bunch of debugging-only rustc flags are basically permaunstable and only available on nightly, which is silly (especially if you need to debug stable)
generally "this will break CI but not end users" should be acceptable IMO, with steps taken to reduce the size of the impact (that's the part that failed here)
generally, rustc has a pretty clear stability policy. cargo does too, informally, though it's a bit more lax in some ways (specifically, things like changing the resolver are in scope)
rustup has historically not changed enough to need one
Hard agree with this, though I disagree that "anticipated" CI usage should be considered okay to break. I think we should document that the output of those flags is unstable and stabilize them!
This is a place where Rust can be better than Go because Go excludes the tooling from this. The rationale is so they can roll out improvements like go modules, but the ecosystem is still recovering from the changes to `go get`.
Comments
The rust backwards compatibility guarantee needs to be expanded to include the official tooling.
this also has negative effects: a bunch of debugging-only rustc flags are basically permaunstable and only available on nightly, which is silly (especially if you need to debug stable)
rustup has historically not changed enough to need one
("everything" isn't acceptable, full 100% stability effectively means never adding features, nothing has full 100% stability)
One could anticipate all kinds of CI breakage on all kinds of rustc PRs and halt development if that were actually the policy
It's a per case tradeoff, IMO.