quite often the answer to a CI breakage is "great, your CI caught a problem, *as is its job*, and the onus is on your side to fix for it". I think that is 100% valid, and views otherwise tend to be super absolutist
Comments
Log in with your Bluesky account to leave a comment
for example, I may soon write a bit of CI that ensures that some of our APIs do not pull in any panic machinery. This is fiddly and can depend on the optimizer. That's fine, if the CI breaks on a rust upgrade, it's on me to investigate how to keep our APIs panic-free, the CI did its job!!
I have in the past had people adamantly claiming that a behavior change on a Unicode repo I maintained (to bring it more in line with the spec!) was a breaking change because their CI broke, and I held the line that no, it wasn't, their CI caught their bad assumptions and *did its job*
I think care can and should be taken to make this path smoother, but I do think it is harmful to view all CI breakage as real breakage, and I do not think this is how the Rust project (implicitly) operates right now
(if the Rust project *thinks* it operates that way, I think it is misinformed)
Sure, that's my point! Nowhere here am I attempting to argue that the rustup change *here* was handled correctly. But I am saying that stability policies are really nuanced and you actually have to spend time coming up with one, not just handwave "we are stable".
*and I'm saying* that "don't break CI" does not make a useful stability policy that I think Rust can meaningfully evolve with. You can have a more nuanced thing around what types of CI breakage are okay, but again, you have to spend time coming up with it
Good points. I agree that absolutist principles should be avoided and it's case by case. I think breaking "intended usage" is closer to the line I had in mind, rather than whether we can anticipate breakage (as you say, Hyrum's law argues in a sense that all breakage should be anticipated)
Comments
(if the Rust project *thinks* it operates that way, I think it is misinformed)