| I am not sure any of what you described can be declared a success in any sense. Failure #1: The language deployed a non-backward compatible change.
Failure #1b: and their ecosystem thinks that's OK. Failure #2: users only saw the need to upgrade the dependency because the language broke that dependency first. So unless they had some other reason to update the given dependency ahead of the compiler upgrade, they would be hit by the problem no matter what. Failure #3: downplaying The importance of the breakage by implying the blast radius would've been smaller if the victim of the first two failures was a lesser known dependency. I can't see any success - of the release process or in any other way. And finally, framing a failure as success is one central problem I have with Rust ecosystem's toxic positivity. In any other healthy community the answer would be "OK, we made a mistake, let's run a post-mortem and do better", or even plain embarrassment - but Rust's ecosystem is the only one in which there's a failure in the joint of two releases processes and claim it as a "success story for [one of the] release process". My hope, as bigger games adopt Rust (US Gov, MS, Linux etc) these attitudes will change. |
I've spent more time writing Hacker News comments about this than I did dealing with it.