Thanks Piotr for starting this discussion. LTS looks better. +1
But I think we should pay attention to how to choose a long-term supported version. Before version planning, we need to carefully consider whether features should be placed in this version or in the next long-term supported version. In other words, when we plan the version, we should clearly distinguish between different versions and formulate different plans. There are some definitions about non-LTS and LTS [1], we may also need some definitions. [1] https://docs.evolveum.com/support/long-term-support/ Best, Jingsong On Fri, Nov 12, 2021 at 12:22 AM DONG, Weike <kyled...@connect.hku.hk> wrote: > > +1 for the LTS proposal, so that existing users do not have to frequently > keep up with the latest Flink version in order to get necessary bug fixes > and security improvements. AFAIK, It is really a burden for them to > upgrade big projects from time to time. > > Best, > Weike > > tison <wander4...@gmail.com>于2021年11月11日 周四下午9:46写道： > > > +1 for the 2nd option. > > > > I met the same problem in another project and just noticed that cherry > > picking > > a lot of versions is a nightmare (especially when the codebase evolves > > rapidly, > > which means CONFLICT). > > > > The LTS option helps us guide users to migrate in prod while we don't have > > to > > slow down developing. I found Java grows well in this pattern. > > > > BTW, shall we also bring this thread to users@ list and listen to our > > users > > with > > their real-world requirements? > > > > Best, > > tison. > > > > > > Piotr Nowojski <pnowoj...@apache.org> 于2021年11月11日周四 下午9:01写道： > > > > > Hi Community, > > > > > > I would like to raise one point that was bothering me for quite a while. > > > Namely this our official policy: > > > > > > > Update Policy for old releases > > > > As of March 2017, the Flink community decided to support the current > > and > > > previous minor > > > > release with bugfixes. If 1.2.x is the current release, 1.1.y is the > > > previous minor supported > > > > release. Both versions will receive bugfixes for critical issues. > > > > > > https://flink.apache.org/downloads.html#update-policy-for-old-releases > > > > > > Plus I think unofficial arrangement, that we are usually back porting bug > > > fixes to two past releases (so one more compared to the official > > support). > > > > > > Officially supporting two past releases is simply not good enough for > > some > > > users. Given that we are aiming for ~3 releases every year, that would > > mean > > > users have to upgrade almost twice a year to keep up with our supported > > > releases. While in reality, the upgrade process is often quite time > > > consuming for the users, and requires significant efforts. On the mailing > > > list I regularly see users struggling with a bug that has been fixed, but > > > not for the versions that they are stuck with. > > > > > > Having said that, I would like to propose to extend the time frame for > > our > > > supported versions in one way or another. I think we should aim to > > provide > > > support for something between 12 and 18 months. I can see two options for > > > how to achieve that: > > > > > > 1. Extend the number of supported releases to at least 4 (latest plus > > three > > > past releases). > > > 2. Introduce some concept of time based Long Term Support. For example > > > periodically marking some flink version as LTS with 18 months of support > > > and additionally maintaining our current policy of supporting two latest > > > releases. This would limit the number of Flink versions that we need to > > > support to just three. > > > > > > Expanding a little bit on the 2nd option, I think we would also need to > > > provide a couple of months for users to upgrade from the previous LTS to > > > the new LTS version. In practice I would imagine it working like that: > > > > > > Flink 1.11.x being the old LTS version that is going to be phased out > > very > > > soon. > > > Flink 1.14.x being the new LTS version > > > Flink 1.13.x maintained as regular release > > > > > > To give enough time for users to migrate between 1.11.x and 1.14.x, we > > > would drop the 1.11.x support with 1.15.0 release. > > > > > > I would be in favour of the 2nd option due to two reasons: > > > - it would provide the ~18 months coverage with fewer supported releases > > > - deciding when to drop old and create new LTS I would base on the time > > > since the last LTS release, not the number of releases. This way users > > > could make long term plans for upgrades regardless of how frequently we > > > manage to create a new release. If we suddenly decide to create 4 or 6 > > > releases a year, LTS users wouldn't be affected. > > > > > > What do you think? > > > > > > Best, > > > Piotrek > > > > > -- Best, Jingsong Lee
