+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 > > >
