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
|