Sorry for the late reply in that matter. I was off the last few days. I should have made this clear in the ML. Anyway, I went over the issues as well. Xintong's summary matches more or less my findings aside from the following items:
- FLINK-4503 (remove deprecated methods from CoGroupedStreams and JoinedStreams) was not mentioned in the above summary (AFAICS) but is most-likely subsumed by the deprecated DataStream API cleanup - FLINK-5875 (using TypeComparator.hash() instead of Object.hashCode()) felt to me like a nice-to-have item because it fixes a bug that was treated with a restrictive workaround. But I see your point that it should have been raised in the ML if it would have been a bigger issue. - FLINK-15470 (remove YARN properties file): Shouldn't we add a log warning and update the documentation as part of 1.18 to make this issue happen? In this sense, I'd say that we should list FLINK-15470 under 1.18 changes necessary Best, Matthias On Wed, Jul 19, 2023 at 10:27 AM Martijn Visser <martijnvis...@apache.org> wrote: > First off, good discussion on these topics. > > +1 on Xintong's latest proposal in this thread > > On Wed, Jul 19, 2023 at 5:16 AM Xintong Song <tonysong...@gmail.com> > wrote: > >> I went through the remaining Jira tickets with 2.0.0 fix-version and are >> not included in FLINK-3975. >> >> I skipped the 3 umbrella tickets below and their subtasks, which are newly >> created for the 2.0 work items. >> >> - FLINK-32377 Breaking REST API changes >> - FLINK-32378 Breaking Metrics system changes >> - FLINK-32383 2.0 Breaking configuration changes >> >> I'd suggest going ahead with the following tickets. >> >> - Need action in 1.18 >> - FLINK-29739: Already listed in the release 2.0 wiki. Needs mark >> all >> Scala APIs as deprecated. >> - Need no action in 1.18 >> - FLINK-23620: Already listed in the release 2.0 >> - FLINK-15470/30246/32437: Behavior changes, no API to be deprecated >> >> I'd suggest not doing the following tickets. >> >> - FLINK-11409: Subsumed by "Convert user-facing concrete classes into >> interfaces" in the release 2.0 wiki >> >> I'd suggest leaving the following tickets as TBD, and would be slightly in >> favor of not doing them unless someone volunteers to look more into them. >> >> - FLINK-10113 Drop support for pre 1.6 shared buffer state >> - FLINK-10374 [Map State] Let user value serializer handle null values >> - FLINK-13928 Make windows api more extendable >> - FLINK-17539 Migrate the configuration options which do not follow the >> xyz.max/min pattern >> >> >> Best, >> >> Xintong >> >> >> >> On Tue, Jul 18, 2023 at 5:20 PM Wencong Liu <liuwencle...@163.com> wrote: >> >> > Hi Chesnay, >> > Thanks for the reply. I think it is reasonable to remove the >> configuration >> > argument >> > in AbstractUdfStreamOperator#open if it is consistently empty. I'll >> > propose a discuss >> > about the specific actions in FLINK-6912 at a later time. >> > >> > >> > Best, >> > Wencong Liu >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > At 2023-07-18 16:38:59, "Chesnay Schepler" <ches...@apache.org> wrote: >> > >On 18/07/2023 10:33, Wencong Liu wrote: >> > >> For FLINK-6912: >> > >> >> > >> There are three implementations of RichFunction that actually >> use >> > >> the Configuration parameter in RichFunction#open: >> > >> 1. ContinuousFileMonitoringFunction#open: It uses the >> configuration >> > >> to configure the FileInputFormat. [1] >> > >> 2. OutputFormatSinkFunction#open: It uses the configuration >> > >> to configure the OutputFormat. [2] >> > >> 3. InputFormatSourceFunction#open: It uses the configuration >> > >> to configure the InputFormat. [3] >> > > >> > >And none of them should have any effect since the configuration is >> empty. >> > > >> > >See >> > org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator#open. >> > >> >
