I think it would be a good to clarify what kind of
backwards-compatibilitiy we're talking about here. As in are we talking
about APIs or savepoints?
On 20.05.2017 19:09, Kostas Kloudas wrote:
Hi all,
As we are getting closer to releasing Flink-1.3, I would like to open a
discussion
on how far back we provide backwards compatibility for.
The reason for opening the discussion is that i) for the users and for the
adoption of the project, it is good to have an explicitely stated policy that
implies
certain guarantees, and ii) keeping code and tests for backwards compatibility
with
Flink-1.1 does not offer much. On the contrary, I think that it leads to:
1) dead or ugly code in the codebase, e.g. deprecated class fields that could
go away and
ugly if() loops (see aligned window operators that were deprecated in 1.2 and
are now
normal windows), etc
2) expensive tests (as, normally, they read from a savepoint)
3) binary files in the codebase for holding the aforementioned savepoints
My proposal for such a policy would be to offer backwards compatibility for one
previous version.
This means that 1.3 will be compatible with 1.2 (not 1.1). This still allows a
clear
"backwards compatibility" path when jumping versions (a user that goes
from 1.1 to 1.3 can go initially 1.1 -> 1.2, take a savepoint, and then 1.2 ->
1.3),
while also allowing us to clean up the codebase a bit.
What do you think?
Kostas
