Hi Kostas, Thanks for bringing this up! I think it is reasonable to keep this coherent with our timely-based release model guarantees.
With the timely-based release model, there is a guarantee that the current latest major version and the previous one is supported. For example, upon releasing 1.3, only 1.3 and 1.2 will still be supported by the community for any required bug fixes. I think this was initially decided not only to ease old version maintenance efforts for the community, but also as a means to let users upgrade their Flink versions in a reasonable pace (at least every other major release.) Therefore, I think its also reasonable to also clearly state that savepoints compatibility will only be guaranteed for the previous release. Although I think at the moment almost, if not all, of the current code still maintains compatibility for 1.1, in the long run these migration codes would definitely start to pile up and pollute the actual codebase if we try to always be compatible with all previous versions. Cheers, Gordon On 21 May 2017 at 2:24:53 AM, Kostas Kloudas (k.klou...@data-artisans.com) wrote: 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 > >
