Hi folks.
We care about not breaking code and put a fair bit of effort into it: we have policies about acceptable breakage; compile new versions of Rust against downstream code; track regressions (somewhat) carefully on the issue tracker, fixing most of them before they hit stable releases; submit patches to downstream projects when we do break them; report breaking changes in commits and release notes. When you consider that Rust, unlike any other language, publishes new revisions every 6 weeks, it’s critically important that our users can feel confident upgrading.
I’ve recently pulled together our data on regressions, and while I don’t have a lot of concrete numbers to present, some eyeballing indicates some trends.
I believe we are doing remarkably well, particularly in comparison to other languages of our maturity and financial backing, but also simply in general. While we do make regular breaking changes (as evident in the 1.5 release notes), most of them are minor and have little or no known downstream impact. Accidental regressions tend to be fixed before hitting stable releases. The major breakage since 1.0 have come from required soundness fixes and ‘API evolution’ matters - that is, additions to the API that have the potential to affect downstream resolution.
Approximately 96% of published crate revisions that build with the 1.0 compiler build with the 1.5 compiler. I think this is a great success.
Our efforts here can be an advantage for Rust in a competitive market - other languages do not seem to be as focused on this.
As Rust grows the impact of breaking changes will be magnified, but fortunately we are getting the soundness fixes out of the way now and the standard library is solidifying. There should be less of the kinds of major breakage we’ve experienced this year going forward. Nevertheless, there are many major features to add to Rust in the future and some of them will require hard decisions. There is more we can do to track regressions, validate changes against downstream projects, and protect ourselves from API evolution fails.
See here the full collection of data, including the tracking spreadsheet categorizing breakage in various ways, the crater reports, the API evolution fails, and the 1.0->1.5 crater run.
Rust rules, y’all.