> version X+1 will remain backward compatible with X but may break compatibility with X-1
That is literally impossible; a breaking change from X-1 to X+1 must have been introduced in one of the intervals X-1 to X or X to X+1. It the latter, X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks compatibility.
Presumably you mean that X always includes warnings about breaking changes in X+1, which is a vast improvement on some projects, but knowing that a problem exists doesn't mean it doesn't exist.
> That is literally impossible; a breaking change from X-1 to X+1 must have been introduced in one of the intervals X-1 to X or X to X+1. It the latter, X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks compatibility.
No, that's not how it works. The deprecation is introduced in version X-1; the new behavior is introduced but is opt-in; in version X, the new behavior becomes opt-out; in version X+1 the old behavior is removed.
That breaks backwards compatibility twice; once in X when 'do_thing' breaks and has to be rewritten as 'enable_thing;do_thing', then again when X+1 causes 'enable_thing;do_thing' to break.
That is literally impossible; a breaking change from X-1 to X+1 must have been introduced in one of the intervals X-1 to X or X to X+1. It the latter, X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks compatibility.
Presumably you mean that X always includes warnings about breaking changes in X+1, which is a vast improvement on some projects, but knowing that a problem exists doesn't mean it doesn't exist.