+1 to LTS. This is good news for users to upgrade their version. We should also publish the version support roadmap on public wiki, just like how Java does [1]. The roadmap should include the LTS support end time, also include the future planning LTS versions.
Best, Jark [1]: https://www.oracle.com/java/technologies/java-se-support-roadmap.html On Fri, 12 Nov 2021 at 10:29, Jingsong Li <jingsongl...@gmail.com> wrote: > 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 >
