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