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 | reasonable). For example, a feature deprecated in mpv 0.30.0 may be removed in | 51 | reasonable). For example, a feature deprecated in mpv 0.30.0 may be removed in |
| 52 | mpv 0.32.0. Minor releases do not count towards this. | 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 | Less useful parts can be broken immediately, but must come with some sort of | 63 | Less useful parts can be broken immediately, but must come with some sort of |
| 55 | removal warning. | 64 | removal warning. |
| 56 | 65 | ||