@@ -83,30 +83,9 @@ features.](./implementing_new_features.md)
8383
8484### Breaking Changes
8585
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
11089
11190### Major Changes
11291
0 commit comments