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