3 ms·

> I think you mean "makes it impossible to know if a release includes backwards incompatible changes without looking at the release notes, while still having a

by knz42 8y ago

> I think you mean "makes it impossible to know if a release includes backwards incompatible changes without looking at the release notes, while still having a release number say nothing about other aspects of the significance of a release." The compatibility guarantees of CockroachDB do not change with this. It's always been the same: version X+1 will remain backward compatible with X but may break compatibility with X-1. Deprecation notices for definitive changes in version X+2 are introduced in version X.

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 ago
  Yes, 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 ago
    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.

by knz42 8y ago

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 ago
Yes, 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 ago
  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.