@@ -83,30 +83,9 @@ features.](./implementing_new_features.md)
83
83
84
84
### Breaking Changes
85
85
86
- As mentioned above, Rust has strong backwards-compatibility guarantees. To this
87
- end, we are reluctant to make breaking changes. However, sometimes they are
88
- needed to correct compiler bugs (e.g. code that compiled but should not) or
89
- make progress on some features.
90
-
91
- Depending on the scale of the breakage, there are a few different actions that
92
- can be taken. If the reviewer believes the breakage is very minimal (i.e. very
93
- unlikely to be actually encountered by users), they may just merge the change.
94
- More often, they will request a Final Comment Period (FCP), which calls for
95
- rough consensus among the members of a relevant team. The team members can
96
- discuss the issue and either accept, reject, or request changes on the PR.
97
-
98
- If the scale of breakage is large, a deprecation warning may be needed. This is
99
- a warning that the compiler will display to users whose code will break in the
100
- future. After some time, an FCP can be used to move forward with the actual
101
- breakage.
102
-
103
- If the scale of breakage is unknown, a team member or contributor may request a
104
- [ crater] run. This is a bot that will compile all crates.io crates and many
105
- public github repos with the compiler with your changes. A report will then be
106
- generated with crates that ceased to compile with or began to compile with your
107
- changes. Crater runs can take a few days to complete.
108
-
109
- [ crater ] : https://github.com/rust-lang/crater
86
+ Breaking changes have a [ dedicated section] [ breaking-changes ] in the dev-guide.
87
+
88
+ [ breaking-changes ] : ./bug-fix-procedure.md
110
89
111
90
### Major Changes
112
91
0 commit comments