Link to bug-fix-procedure.md from the contribution procedure section
This commit is contained in:
parent
92102e0e8c
commit
161b9b3beb
|
|
@ -40,7 +40,7 @@
|
|||
- [Using Git](./git.md)
|
||||
- [Mastering @rustbot](./rustbot.md)
|
||||
- [Walkthrough: a typical contribution](./walkthrough.md)
|
||||
- [Bug Fix Procedure](./bug-fix-procedure.md)
|
||||
- [Procedures for Breaking Changes](./bug-fix-procedure.md)
|
||||
- [Implementing new features](./implementing_new_features.md)
|
||||
- [Stability attributes](./stability.md)
|
||||
- [Stabilizing Features](./stabilization_guide.md)
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Rustc Bug Fix Procedure
|
||||
# Procedures for Breaking Changes
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
|
|
@ -169,6 +169,13 @@ there were no errors before.
|
|||
|
||||
#### Crater and crates.io
|
||||
|
||||
[Crater] is a bot that will compile all crates.io crates and many
|
||||
public github repos with the compiler with your changes. A report will then be
|
||||
generated with crates that ceased to compile with or began to compile with your
|
||||
changes. Crater runs can take a few days to complete.
|
||||
|
||||
[Crater]: https://github.com/rust-lang/crater
|
||||
|
||||
We should always do a crater run to assess impact. It is polite and considerate
|
||||
to at least notify the authors of affected crates the breaking change. If we can
|
||||
submit PRs to fix the problem, so much the better.
|
||||
|
|
|
|||
|
|
@ -83,30 +83,9 @@ features.](./implementing_new_features.md)
|
|||
|
||||
### Breaking Changes
|
||||
|
||||
As mentioned above, Rust has strong backwards-compatibility guarantees. To this
|
||||
end, we are reluctant to make breaking changes. However, sometimes they are
|
||||
needed to correct compiler bugs (e.g. code that compiled but should not) or
|
||||
make progress on some features.
|
||||
Breaking changes have a [dedicated section][breaking-changes] in the dev-guide.
|
||||
|
||||
Depending on the scale of the breakage, there are a few different actions that
|
||||
can be taken. If the reviewer believes the breakage is very minimal (i.e. very
|
||||
unlikely to be actually encountered by users), they may just merge the change.
|
||||
More often, they will request a Final Comment Period (FCP), which calls for
|
||||
rough consensus among the members of a relevant team. The team members can
|
||||
discuss the issue and either accept, reject, or request changes on the PR.
|
||||
|
||||
If the scale of breakage is large, a deprecation warning may be needed. This is
|
||||
a warning that the compiler will display to users whose code will break in the
|
||||
future. After some time, an FCP can be used to move forward with the actual
|
||||
breakage.
|
||||
|
||||
If the scale of breakage is unknown, a team member or contributor may request a
|
||||
[crater] run. This is a bot that will compile all crates.io crates and many
|
||||
public github repos with the compiler with your changes. A report will then be
|
||||
generated with crates that ceased to compile with or began to compile with your
|
||||
changes. Crater runs can take a few days to complete.
|
||||
|
||||
[crater]: https://github.com/rust-lang/crater
|
||||
[breaking-changes]: ./bug-fix-procedure.md
|
||||
|
||||
### Major Changes
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue