3 ms·

Ah that makes sense. I suppose you can't predict naming in everyone's source for their projects. Thanks for the answer!

steveklabnik 9y ago
No worries. There is also other things as well, that's just one of the easiest ones to explain. For example, in 1.20 last week, we fixed a bug with include! in documentation tests behaving strangely; that's technically a change in behavior, and therefore, a breaking change. Two crates were the only users, apparently, and so they just wrote a patch and fixed it. Still technically breakage. The guiding principle is "it should not be painful to update the compiler", and I think we do as good a job as we can making sure that that's true.
- nickm12 9y ago
  It would be helpful in these guidelines to make a clear distinction between changes that result in "code not compiling" versus "code behaving differently". It seems like the vast majority of cases you've enumerated are in the category of "code won't compile". Perhaps some have a knee-jerk reaction against this, but to me this is kind of incompatibility seems much more preferable to the other, especially if the update required to the code is trivial and obvious.
Manishearth 9y ago
To expand on this, we consider the following changes to be okay or "not really a breaking change" (see also: https://blog.rust-lang.org/2014/10/30/Stability.html#what-are-the-stability-caveats https://blog.rust-lang.org/2014/10/30/Stability.html#what-ar...): - Patching up soundness holes causing previously-unsound code to error (https://github.com/rust-lang/rust/pull/43651 https://github.com/rust-lang/rust/pull/43651 is an example) - Changing inference in a way that may require new annotations - Adding types and things to modules which may cause clashes on glob imports (steve's example above) - Adding methods to types (this may cause code calling trait methods to require disambiguation via the fully qualified UFCS syntax) - Adding new trait impls (similar disambiguation issues) - Lint changes (If you `#[deny(lint)]` a lint, this may cause compilation failures). Cargo passes --cap-lints=warn to dependencies so a lint change will at most cause your dependencies to spew extra warnings and cause your code to stop compiling, in a way that's trivial to fix (allow the lint, or fix the warning). In general for all releases we run cargobomb to look out for breakages, both "okay" ones and not okay ones. Additionally, for the first two kinds of breakages (and other miscellaneous iffy changes) we proactively cargobomb. Even if something is technically allowed by our stability rules we want to make sure that practically speaking it has minimal impact.

No worries. There is also other things as well, that's just one of the easiest ones to explain. For example, in 1.20 last week, we fixed a bug with include! in documentation tests behaving strangely; that's technically a change in behavior, and therefore, a breaking change. Two crates were the only users, apparently, and so they just wrote a patch and fixed it. Still technically breakage. The guiding principle is "it should not be painful to update the compiler", and I think we do as good a job as we can making sure that that's true.

nickm12 9y ago
It would be helpful in these guidelines to make a clear distinction between changes that result in "code not compiling" versus "code behaving differently". It seems like the vast majority of cases you've enumerated are in the category of "code won't compile". Perhaps some have a knee-jerk reaction against this, but to me this is kind of incompatibility seems much more preferable to the other, especially if the update required to the code is trivial and obvious.

Manishearth 9y ago

To expand on this, we consider the following changes to be okay or "not really a breaking change" (see also: https://blog.rust-lang.org/2014/10/30/Stability.html#what-are-the-stability-caveats https://blog.rust-lang.org/2014/10/30/Stability.html#what-ar...): - Patching up soundness holes causing previously-unsound code to error (https://github.com/rust-lang/rust/pull/43651 https://github.com/rust-lang/rust/pull/43651 is an example) - Changing inference in a way that may require new annotations - Adding types and things to modules which may cause clashes on glob imports (steve's example above) - Adding methods to types (this may cause code calling trait methods to require disambiguation via the fully qualified UFCS syntax) - Adding new trait impls (similar disambiguation issues) - Lint changes (If you `#[deny(lint)]` a lint, this may cause compilation failures). Cargo passes --cap-lints=warn to dependencies so a lint change will at most cause your dependencies to spew extra warnings and cause your code to stop compiling, in a way that's trivial to fix (allow the lint, or fix the warning). In general for all releases we run cargobomb to look out for breakages, both "okay" ones and not okay ones. Additionally, for the first two kinds of breakages (and other miscellaneous iffy changes) we proactively cargobomb. Even if something is technically allowed by our stability rules we want to make sure that practically speaking it has minimal impact.