Thanks for the comprehensive explanation. It is clear now. Best regards, Jing
On Fri, Oct 14, 2022 at 9:51 AM Matthias Pohl <matthias.p...@aiven.io.invalid> wrote: > Ok, a bit of back-and-forth reading. :-D Thanks for the example. It sounds > reasonable. > > +1 (binding) > > On Thu, Oct 13, 2022 at 8:33 PM Chesnay Schepler <ches...@apache.org> > wrote: > > > I will write this all down in the wiki once the vote is over, but here > > are some example. > > > > > > Let's start out with a happy-case scenario with one connector supporting > > the last 2 Flink versions. > > This will commonly be the scenario for connectors when they have been > > externalized: > > > > v1: 1.14-1.15 > > > > > > Now we create a v2 that only support 1.15: > > > > v1: 1.14-1.15 (patch support) > > v2: 1.15 (feature support) > > > > 4.1) kicks in, both versions getting support, but only the latest > > getting new features. > > > > > > Now 1.16 is released, which v2 also supports. > > > > v1: 1.14-1.15 (patch support) > > v2: 1.15-1.16 (feature support) > > > > Nothing changes. > > > > > > Now 1.17 is released: > > > > v1: 1.14-1.15 (no support) > > v2: 1.15-1.17 > > > > Here 4.1.a kicks in; v1 supports no supported Flink version and lost > > support. > > > > > > Now we create v3 targeting 1.17, and shortly thereafter v4, also > > targeting 1.17, because we messed something up or are just that excited > > about finally having major releases. > > > > v2: 1.15-1.17 (patch support) > > v3: 1.17 (patch support) > > v4: 1.17 (feature support) > > > > Here 4.1.b kicks in, ensuring that v2 is still supported since we need > > to support all Flink versions. > > > > > > Now 1.18 is released, with v3 and v4 supporting it. > > > > v2: 1.15-1.17 (no support) > > v3: 1.17 (patch support) > > v4: 1.17 (feature support) > > > > General 4.1) rule kicks in, with only the last 2 major versions being > > supported. > > > > On 13/10/2022 16:25, Jing Ge wrote: > > > +1 and I would suggest giving a concrete example to explain 4) support. > > It > > > is still not quite easy to understand the text. Not many (future) > > connector > > > developers could join this discussion. It is better to make it as clear > > as > > > possible at the beginning than spend more time explaining multiple > times. > > > Just my two cents. > > > > > > Best regards, > > > Jing > > > > > > On Thu, Oct 13, 2022 at 2:02 PM Ryan Skraba > <ryan.skr...@aiven.io.invalid > > > > > > wrote: > > > > > >> +1 non-binding! I've been following (and generally agreeing) with the > > >> thread -- it's a perfectly reasonable way to start, and I'm sure we > can > > >> adjust the process if it turns out to be unsuitable or unexpected as > the > > >> connectors evolve in their external repositories. > > >> > > >> On Thu, Oct 13, 2022 at 12:37 PM Thomas Weise <t...@apache.org> wrote: > > >> > > >>> +1 (binding) for the vote and thanks for the explanation > > >>> > > >>> On Thu, Oct 13, 2022 at 5:58 AM Chesnay Schepler <ches...@apache.org > > > > >>> wrote: > > >>> > > >>>> @Thomas: > > >>>> Version-specific modules that either contain a connector or shims to > > >>>> support that Flink version. > > >>>> Alternatively, since the addition of such code (usually) goes > beyond a > > >>>> patch release you'd create a new minor version and could have that > > only > > >>>> support the later version. > > >>>> > > >>>> On 13/10/2022 02:05, Thomas Weise wrote: > > >>>>> "Branches are not specific to a Flink version. (i.e., no > v3.2-1.15)" > > >>>>> > > >>>>> Sorry for the late question. I could not find in the discussion > > >> thread > > >>>> how > > >>>>> a connector can make use of features of the latest Flink version > that > > >>>> were > > >>>>> not present in the previous Flink version, when branches cannot be > > >>> Flink > > >>>>> version specific? > > >>>>> > > >>>>> Thanks, > > >>>>> Thomas > > >>>>> > > >>>>> On Wed, Oct 12, 2022 at 4:09 PM Ferenc Csaky > > >>> <ferenc.cs...@pm.me.invalid > > >>>>> wrote: > > >>>>> > > >>>>>> +1 from my side (non-binding) > > >>>>>> > > >>>>>> Best, > > >>>>>> F > > >>>>>> > > >>>>>> > > >>>>>> ------- Original Message ------- > > >>>>>> On Wednesday, October 12th, 2022 at 15:47, Martijn Visser < > > >>>>>> martijnvis...@apache.org> wrote: > > >>>>>> > > >>>>>> > > >>>>>>> +1 (binding), I am indeed assuming that Chesnay meant the last > two > > >>>> minor > > >>>>>>> versions as supported. > > >>>>>>> > > >>>>>>> Op wo 12 okt. 2022 om 20:18 schreef Danny Cranmer > > >>>>>> dannycran...@apache.org > > >>>>>>>> Thanks for the concise summary Chesnay. > > >>>>>>>> > > >>>>>>>> +1 from me (binding) > > >>>>>>>> > > >>>>>>>> Just one clarification, for "3.1) The Flink versions supported > by > > >>> the > > >>>>>>>> project (last 2 major Flink versions) must be supported.". Do we > > >>>>>> actually > > >>>>>>>> mean major here, as in Flink 1.x.x and 2.x.x? Right now we would > > >>> only > > >>>>>>>> support Flink 1.15.x and not 1.14.x? I would be inclined to > > >> support > > >>>> the > > >>>>>>>> latest 2 minor Flink versions (major.minor.patch) given that we > > >> only > > >>>>>> have 1 > > >>>>>>>> active major Flink version. > > >>>>>>>> > > >>>>>>>> Danny > > >>>>>>>> > > >>>>>>>> On Wed, Oct 12, 2022 at 2:12 PM Chesnay Schepler > > >> ches...@apache.org > > >>>>>>>> wrote: > > >>>>>>>> > > >>>>>>>>> Since the discussion > > >>>>>>>>> ( > > >> https://lists.apache.org/thread/mpzzlpob9ymkjfybm96vz2y2m5fjyvfo) > > >>>>>> has > > >>>>>>>>> stalled a bit but we need a conclusion to move forward I'm > > >> opening > > >>> a > > >>>>>>>>> vote. > > >>>>>>>>> > > >>>>>>>>> Proposal summary: > > >>>>>>>>> > > >>>>>>>>> 1) Branch model > > >>>>>>>>> 1.1) The default branch is called "main" and used for the next > > >>> major > > >>>>>>>>> iteration. > > >>>>>>>>> 1.2) Remaining branches are called "vmajor.minor". (e.g., v3.2) > > >>>>>>>>> 1.3) Branches are not specific to a Flink version. (i.e., no > > >>>>>> v3.2-1.15) > > >>>>>>>>> 2) Versioning > > >>>>>>>>> 2.1) Source releases: major.minor.patch > > >>>>>>>>> 2.2) Jar artifacts: major.minor.match-flink-major.flink-minor > > >>>>>>>>> (This may imply releasing the exact same connector jar multiple > > >>> times > > >>>>>>>>> under different versions) > > >>>>>>>>> > > >>>>>>>>> 3) Flink compatibility > > >>>>>>>>> 3.1) The Flink versions supported by the project (last 2 major > > >>> Flink > > >>>>>>>>> versions) must be supported. > > >>>>>>>>> 3.2) How this is achived is left to the connector, as long as > it > > >>>>>>>>> conforms to the rest of the proposal. > > >>>>>>>>> > > >>>>>>>>> 4) Support > > >>>>>>>>> 4.1) The last 2 major connector releases are supported with > only > > >>> the > > >>>>>>>>> latter receiving additional features, with the following > > >>> exceptions: > > >>>>>>>>> 4.1.a) If the older major connector version does not support > any > > >>>>>>>>> currently supported Flink version, then it is no longer > > >> supported. > > >>>>>>>>> 4.1.b) If the last 2 major versions do not cover all supported > > >>> Flink > > >>>>>>>>> versions, then the latest connector version that supports the > > >> older > > >>>>>>>>> Flink version /additionally /gets patch support. > > >>>>>>>>> 4.2) For a given major connector version only the latest minor > > >>>>>> version > > >>>>>>>>> is supported. > > >>>>>>>>> (This means if 1.1.x is released there will be no more 1.0.x > > >>> release) > > >>>>>>>>> I'd like to clarify that these won't be set in stone for > > >> eternity. > > >>>>>>>>> We should re-evaluate how well this model works over time and > > >>> adjust > > >>>>>> it > > >>>>>>>>> accordingly, consistently across all connectors. > > >>>>>>>>> I do believe that as is this strikes a good balance between > > >>>>>>>>> maintainability for us and clarity to users. > > >>>>>>>>> > > >>>>>>>>> Voting schema: > > >>>>>>>>> > > >>>>>>>>> Consensus, committers have binding votes, open for at least 72 > > >>> hours. > > >>>>>>> -- > > >>>>>>> Martijn > > >>>>>>> https://twitter.com/MartijnVisser82 > > >>>>>>> https://github.com/MartijnVisser > > >>>> > > >>>> > > > > >
