We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
We should document which kind of changes are breaking and cannot be made to stable APIs.
E.g. changing a function from fn(i32) to fn(impl Into<i32>) can be breaking, but relaxing a <T: Ord> to <T: PartialOrd> might be fine (maybe?).
fn(i32)
fn(impl Into<i32>)
<T: Ord>
<T: PartialOrd>
The text was updated successfully, but these errors were encountered:
And also, what level of breakage is acceptable. E.g., if a Crater run shows very few regressions, it's sometimes acceptable to make a breaking change.
Sorry, something went wrong.
We've got a section with some initial content here: https://github.com/rust-lang/std-dev-guide/tree/master/src/code-considerations/breaking-changes
There's still lots we could expand there!
I think it's usually inference that causes us the most pain in all kinds of changes that add trait impls and relax bounds.
No branches or pull requests
We should document which kind of changes are breaking and cannot be made to stable APIs.
E.g. changing a function from
fn(i32)
tofn(impl Into<i32>)
can be breaking, but relaxing a<T: Ord>
to<T: PartialOrd>
might be fine (maybe?).The text was updated successfully, but these errors were encountered: