calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
Subject Re: Breaking changes and internal APIs
Date Tue, 07 May 2019 15:48:46 GMT
Stamatis> While doing code-reviews there are times that I observe changes

Stamatis, thanks for raising the question.
I was about to raise it (e.g. regarding join refactoring), however it is
great the issue bothers more than just myself.

Calcite follows semantic versioning policy.

As you might know "C" in Calcite stands for consistency, so Calcite
consistently sacrifices backward compatibility in favour of new features.

Apparently the only way to solve it is to setup some kind of automatic
verification of API compatibility.
The most simple things are "binary/source compatibility" (e.g. method
renamed/removed), however there are more complicated things like "change in
behavour" (e.g. method call sequence is altered)

The thing is Calcite can be used in 100500 ways, so no single
"incompatible" change hits 100% of the users.
For instance, "join refactoring" does defeat mat-calcite-plugin (e.g.
https://github.com/vlsi/mat-calcite-plugin/blob/8c774d820859636c3921597eb0940295acbff191/MatCalcitePlugin/src/com/github/vlsi/mat/calcite/Query.java#L32
), however it is not like a showstopper.
However, it is truly unamusing to have those breaking changes in "feature"
releases like 1.20.

Vladimir

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message