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
