I can’t find when the time-based maintenance schedule switched from “6 months” to “2 concurrent versions” (which has not yet made it into the website [0]). Is it correct to assume that most users are waiting until the first bug fix release or later to upgrade? That only leaves a narrow window of stability.
Greg [0] https://github.com/apache/flink-web/pull/50 > On May 22, 2017, at 1:39 AM, Tzu-Li (Gordon) Tai <tzuli...@apache.org> wrote: > > 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
