14 ms·
> 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
by a1369209993 8y ago
> 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.
- jrochkind1 8y agoYes, it means X+1 is backwards compatible with X so long as no deprecation notices were produced by your use in X. I get it, and find it reasonable.
- knz42 8y ago> 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.
- a1369209993 8y agoThat 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.