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