Currently there is no policy on what should be done when an immediate, severe breakage happens for "important/often used parts", which can cause serious concerns especially if such changes remain obscured. This adds a provision for this kind of incompatible changes under "extraordinary circumstances", which allows for the breaking change to happen if there is a critical reason to do so. Such changes must be extensively documented, and should be avoided as much as possible.
Unified · Split
| @@ -51,6 +51,15 @@ functionality still works, and a replacement is available (if technically · 50 unmodified lines | ||
| 51 | 51 | reasonable). For example, a feature deprecated in mpv 0.30.0 may be removed in |
| 52 | 52 | mpv 0.32.0. Minor releases do not count towards this. |
| 53 | 53 | |
| 54 | +Under extraordinary circumstances, such as missed incompatible changes that are | |
| 55 | +already included in a release, critical security fixes, or a severe shortage of | |
| 56 | +developer time to address the known incompatible changes, important/often used | |
| 57 | +parts may be broken immediately, but the change must be extensively documented: | |
| 58 | +all of the related documentations (including manpage, interface-changes.rst, | |
| 59 | +etc., retrospectively modified if applicable) must clearly state the following: | |
| 60 | +the fact that the change is a breaking change; the version when the breaking | |
| 61 | +change happened; and the reason, impact, and suggested remedy actions. | |
| 62 | + | |
| 54 | 63 | Less useful parts can be broken immediately, but must come with some sort of |
| 55 | 64 | removal warning. |
| 56 | 65 | |