You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Chesnay Schepler <ch...@apache.org> on 2022/10/12 13:12:21 UTC
[VOTE] Externalized connector release details&workflow
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.
Re: [VOTE] Externalized connector release details&workflow
Posted by Chesnay Schepler <ch...@apache.org>.
Of course we can (and will).
That will happen at a later time once we get a bit of use out of it to
iterate faster.
On 20/10/2022 18:23, Steven Wu wrote:
> Chesnay, thanks for the write-up. very helpful!
>
> Regarding the parent pom, I am wondering if it can be published to the
> `org.apache.flink` group?
>
> <parent>
> <groupId>io.github.zentol.flink</groupId>
> <artifactId>flink-connector-parent</artifactId>
> <version>1.0</version>
> </parent>
>
> On Mon, Oct 17, 2022 at 5:52 AM Chesnay Schepler <ch...@apache.org> wrote:
>
>> https://cwiki.apache.org/confluence/display/FLINK/Externalized+Connector+development
>>
>> On 17/10/2022 13:13, Chesnay Schepler wrote:
>>> The vote has passed unanimously.
>>>
>>> +1 Votes:
>>> - Danny (binding)
>>> - Martijn (binding)
>>> - Ferenc (non-binding)
>>> - Thomas (binding)
>>> - Ryan (non-binding)
>>> - Jing (non-binding)
>>> - Matthias (binding)
>>>
>>> I will now document this in the wiki and start working on the release
>>> scripts.
>>>
>>> On 12/10/2022 15:12, Chesnay Schepler 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.
>>>>
>>
Re: [VOTE] Externalized connector release details&workflow
Posted by Steven Wu <st...@gmail.com>.
Chesnay, thanks for the write-up. very helpful!
Regarding the parent pom, I am wondering if it can be published to the
`org.apache.flink` group?
<parent>
<groupId>io.github.zentol.flink</groupId>
<artifactId>flink-connector-parent</artifactId>
<version>1.0</version>
</parent>
On Mon, Oct 17, 2022 at 5:52 AM Chesnay Schepler <ch...@apache.org> wrote:
>
> https://cwiki.apache.org/confluence/display/FLINK/Externalized+Connector+development
>
> On 17/10/2022 13:13, Chesnay Schepler wrote:
> > The vote has passed unanimously.
> >
> > +1 Votes:
> > - Danny (binding)
> > - Martijn (binding)
> > - Ferenc (non-binding)
> > - Thomas (binding)
> > - Ryan (non-binding)
> > - Jing (non-binding)
> > - Matthias (binding)
> >
> > I will now document this in the wiki and start working on the release
> > scripts.
> >
> > On 12/10/2022 15:12, Chesnay Schepler 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.
> >>
> >
>
>
Re: [VOTE] Externalized connector release details&workflow
Posted by Chesnay Schepler <ch...@apache.org>.
https://cwiki.apache.org/confluence/display/FLINK/Externalized+Connector+development
On 17/10/2022 13:13, Chesnay Schepler wrote:
> The vote has passed unanimously.
>
> +1 Votes:
> - Danny (binding)
> - Martijn (binding)
> - Ferenc (non-binding)
> - Thomas (binding)
> - Ryan (non-binding)
> - Jing (non-binding)
> - Matthias (binding)
>
> I will now document this in the wiki and start working on the release
> scripts.
>
> On 12/10/2022 15:12, Chesnay Schepler 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.
>>
>
Re: [VOTE] Externalized connector release details&workflow
Posted by Chesnay Schepler <ch...@apache.org>.
The vote has passed unanimously.
+1 Votes:
- Danny (binding)
- Martijn (binding)
- Ferenc (non-binding)
- Thomas (binding)
- Ryan (non-binding)
- Jing (non-binding)
- Matthias (binding)
I will now document this in the wiki and start working on the release
scripts.
On 12/10/2022 15:12, Chesnay Schepler 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.
>
Re: [VOTE] Externalized connector release details&workflow
Posted by Jing Ge <ji...@ververica.com>.
Thanks for the comprehensive explanation. It is clear now.
Best regards,
Jing
On Fri, Oct 14, 2022 at 9:51 AM Matthias Pohl
<ma...@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 <ch...@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.skraba@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 <th...@apache.org> wrote:
> > >>
> > >>> +1 (binding) for the vote and thanks for the explanation
> > >>>
> > >>> On Thu, Oct 13, 2022 at 5:58 AM Chesnay Schepler <chesnay@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.csaky@pm.me.invalid
> > >>>>> wrote:
> > >>>>>
> > >>>>>> +1 from my side (non-binding)
> > >>>>>>
> > >>>>>> Best,
> > >>>>>> F
> > >>>>>>
> > >>>>>>
> > >>>>>> ------- Original Message -------
> > >>>>>> On Wednesday, October 12th, 2022 at 15:47, Martijn Visser <
> > >>>>>> martijnvisser@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
> > >>>>>> dannycranmer@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
> > >> chesnay@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
> > >>>>
> > >>>>
> >
> >
>
Re: [VOTE] Externalized connector release details&workflow
Posted by Matthias Pohl <ma...@aiven.io.INVALID>.
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 <ch...@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.skraba@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 <th...@apache.org> wrote:
> >>
> >>> +1 (binding) for the vote and thanks for the explanation
> >>>
> >>> On Thu, Oct 13, 2022 at 5:58 AM Chesnay Schepler <ch...@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.csaky@pm.me.invalid
> >>>>> wrote:
> >>>>>
> >>>>>> +1 from my side (non-binding)
> >>>>>>
> >>>>>> Best,
> >>>>>> F
> >>>>>>
> >>>>>>
> >>>>>> ------- Original Message -------
> >>>>>> On Wednesday, October 12th, 2022 at 15:47, Martijn Visser <
> >>>>>> martijnvisser@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
> >>>>>> dannycranmer@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
> >> chesnay@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
> >>>>
> >>>>
>
>
Re: [VOTE] Externalized connector release details&workflow
Posted by Chesnay Schepler <ch...@apache.org>.
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 <ry...@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 <th...@apache.org> wrote:
>>
>>> +1 (binding) for the vote and thanks for the explanation
>>>
>>> On Thu, Oct 13, 2022 at 5:58 AM Chesnay Schepler <ch...@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.csaky@pm.me.invalid
>>>>> wrote:
>>>>>
>>>>>> +1 from my side (non-binding)
>>>>>>
>>>>>> Best,
>>>>>> F
>>>>>>
>>>>>>
>>>>>> ------- Original Message -------
>>>>>> On Wednesday, October 12th, 2022 at 15:47, Martijn Visser <
>>>>>> martijnvisser@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
>>>>>> dannycranmer@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
>> chesnay@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
>>>>
>>>>
Re: [VOTE] Externalized connector release details&workflow
Posted by Jing Ge <ji...@ververica.com>.
+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 <ry...@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 <th...@apache.org> wrote:
>
> > +1 (binding) for the vote and thanks for the explanation
> >
> > On Thu, Oct 13, 2022 at 5:58 AM Chesnay Schepler <ch...@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.csaky@pm.me.invalid
> > > >
> > > > wrote:
> > > >
> > > >> +1 from my side (non-binding)
> > > >>
> > > >> Best,
> > > >> F
> > > >>
> > > >>
> > > >> ------- Original Message -------
> > > >> On Wednesday, October 12th, 2022 at 15:47, Martijn Visser <
> > > >> martijnvisser@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
> > > >> dannycranmer@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
> chesnay@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
> > >
> > >
> > >
> >
>
Re: [VOTE] Externalized connector release details&workflow
Posted by Ryan Skraba <ry...@aiven.io.INVALID>.
+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 <th...@apache.org> wrote:
> +1 (binding) for the vote and thanks for the explanation
>
> On Thu, Oct 13, 2022 at 5:58 AM Chesnay Schepler <ch...@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.csaky@pm.me.invalid
> > >
> > > wrote:
> > >
> > >> +1 from my side (non-binding)
> > >>
> > >> Best,
> > >> F
> > >>
> > >>
> > >> ------- Original Message -------
> > >> On Wednesday, October 12th, 2022 at 15:47, Martijn Visser <
> > >> martijnvisser@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
> > >> dannycranmer@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 chesnay@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
> >
> >
> >
>
Re: [VOTE] Externalized connector release details&workflow
Posted by Thomas Weise <th...@apache.org>.
+1 (binding) for the vote and thanks for the explanation
On Thu, Oct 13, 2022 at 5:58 AM Chesnay Schepler <ch...@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.csaky@pm.me.invalid
> >
> > wrote:
> >
> >> +1 from my side (non-binding)
> >>
> >> Best,
> >> F
> >>
> >>
> >> ------- Original Message -------
> >> On Wednesday, October 12th, 2022 at 15:47, Martijn Visser <
> >> martijnvisser@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
> >> dannycranmer@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 chesnay@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
>
>
>
Re: [VOTE] Externalized connector release details&workflow
Posted by Chesnay Schepler <ch...@apache.org>.
@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 <fe...@pm.me.invalid>
> wrote:
>
>> +1 from my side (non-binding)
>>
>> Best,
>> F
>>
>>
>> ------- Original Message -------
>> On Wednesday, October 12th, 2022 at 15:47, Martijn Visser <
>> martijnvisser@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
>> dannycranmer@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 chesnay@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
Re: [VOTE] Externalized connector release details&workflow
Posted by Thomas Weise <th...@apache.org>.
"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 <fe...@pm.me.invalid>
wrote:
> +1 from my side (non-binding)
>
> Best,
> F
>
>
> ------- Original Message -------
> On Wednesday, October 12th, 2022 at 15:47, Martijn Visser <
> martijnvisser@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
> dannycranmer@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 chesnay@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
>
Re: [VOTE] Externalized connector release details&workflow
Posted by Ferenc Csaky <fe...@pm.me.INVALID>.
+1 from my side (non-binding)
Best,
F
------- Original Message -------
On Wednesday, October 12th, 2022 at 15:47, Martijn Visser <ma...@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 dannycranmer@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 chesnay@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
Re: [VOTE] Externalized connector release details&workflow
Posted by Martijn Visser <ma...@apache.org>.
+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 <da...@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 <ch...@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
Re: [VOTE] Externalized connector release details&workflow
Posted by Chesnay Schepler <ch...@apache.org>.
I mean minor. I always get confused on the Flink side because we use
"major" instead of "minor" releases in many places.
On 12/10/2022 20:18, Danny Cranmer wrote:
> 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 <ch...@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.
>>
Re: [VOTE] Externalized connector release details&workflow
Posted by Danny Cranmer <da...@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 <ch...@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.
>