I also don't think we should block new feature development until 2.0. From my understanding, the new major release is no different from the regular minor releases for new features.
I think tracking new features, either as nice-to-have items or in a separate list, is necessary. It helps us understand what's going on in the release cycle, and what to announce and promote. Maybe we should start a discussion on updating the 2.0 item list, to 1) collect new items that are proposed / initiated after the original list being created and 2) to remove some items that are no longer suitable. I'll discuss this with the other release managers first. For the connectors and operators, I think it depends on whether they depend on any deprecated APIs or internal implementations of Flink. Ideally, all @Public APIs and @PublicEvolving APIs that we plan to change / remove should have been deprecated in 1.19 and 1.20 respectively. That means if the connectors and operators only use non-deprecated @Puclib and @PublicEvolving APIs in 1.20, hopefully there should not be any problems upgrading to 2.0. Best, Xintong On Wed, Jun 26, 2024 at 5:20 AM Becket Qin <becket....@gmail.com> wrote: > Thanks for the question, Matthias. > > My two cents, I don't think we are blocking new feature development. My > understanding is that the community will just prioritize removing > deprecated APIs in the 2.0 dev cycle. Because of that, it is possible that > some new feature development may slow down a little bit since some > contributors may be working on the must-have features for 2.0. But policy > wise, I don't see a reason to block the new feature development for the 2.0 > release feature plan[1]. > > Process wise, I like your idea of adding the new features as nice-to-have > in the 2.0 feature list. > > Re: David, > Given it is a major version bump. It is possible that some of the > downstream projects (e.g. connectors, Paimon, etc) will have to see if a > major version bump is also needed there. And it is probably going to be > decisions made on a per-project basis. > Regarding the Java version specifically, this probably worth a separate > discussion. According to a recent report[2] on the state of Java, it might > be a little early to drop support for Java 11. We can discuss this > separately. > > Thanks, > > Jiangjie (Becket) Qin > > [1] https://cwiki.apache.org/confluence/display/FLINK/2.0+Release > [2] > > https://newrelic.com/sites/default/files/2024-04/new-relic-state-of-the-java-ecosystem-report-2024-04-30.pdf > > On Tue, Jun 25, 2024 at 4:58 AM David Radley <david_rad...@uk.ibm.com> > wrote: > > > Hi, > > I think this is a great question. I am not sure if this has been covered > > elsewhere, but it would be good to be clear how this effects the > connectors > > and operator repos, with potentially v1 and v2 oriented new featuresI > > suspect this will be a connector by connector investigation. I am > thinking > > connectors with Hadoop eco-system dependencies (e.g. Paimon) which may > not > > work nicely with Java 17, > > > > Kind regards, David. > > > > > > From: Matthias Pohl <map...@apache.org> > > Date: Tuesday, 25 June 2024 at 09:57 > > To: dev@flink.apache.org <dev@flink.apache.org> > > Cc: Xintong Song <tonysong...@gmail.com>, martijnvis...@apache.org < > > martijnvis...@apache.org>, imj...@gmail.com <imj...@gmail.com>, > > becket....@gmail.com <becket....@gmail.com> > > Subject: [EXTERNAL] [2.0] How to handle on-going feature development in > > Flink 2.0? > > Hi 2.0 release managers, > > With the 1.20 release branch being cut [1], master is now referring to > > 2.0-SNAPSHOT. I remember that, initially, the community had the idea of > > keeping the 2.0 release as small as possible focusing on API changes [2]. > > > > What does this mean for new features? I guess blocking them until 2.0 is > > released is not a good option. Shall we treat new features as > > "nice-to-have" items as documented in the 2.0 release overview [3] and > > merge them to master like it was done for minor releases in the past? Do > > you want to add a separate section in the 2.0 release overview [3] to > list > > these new features (e.g. FLIP-461 [4]) separately? That might help to > > manage planned 2.0 deprecations/API removal and new features separately. > Or > > do you have a different process in mind? > > > > Apologies if this was already discussed somewhere. I didn't manage to > find > > anything related to this topic. > > > > Best, > > Matthias > > > > [1] https://lists.apache.org/thread/mwnfd7o10xo6ynx0n640pw9v2opbkm8l > > [2] https://lists.apache.org/thread/b8w5cx0qqbwzzklyn5xxf54vw9ymys1c > > [3] https://cwiki.apache.org/confluence/display/FLINK/2.0+Release > > [4] > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-461%3A+Synchronize+rescaling+with+checkpoint+creation+to+minimize+reprocessing+for+the+AdaptiveScheduler > > > > Unless otherwise stated above: > > > > IBM United Kingdom Limited > > Registered in England and Wales with number 741598 > > Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU > > >
