Hi Chesnay, I believe that for APIs we already have a pretty clear policy with the annotations. I was referring to savepoints and state related backwards compatibility.
> On May 20, 2017, at 7:20 PM, Chesnay Schepler <ches...@apache.org> wrote: > > 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 > >
