Hi all,
Initially, I thought aligning with each Flink version — 5.0.0-2.1 and 6.0.0-2.2
— made sense.
However, as Ferenc pointed out, given that the Source/Sink API usage should
preserve backward compatibility, 4.1.0-{flink_version} seems like the more
appropriate approach.
That said, if any compatibility issues are found during testing, then going
with 5.0.0-2.1 and 5.0.0-2.2 would be the right call.
Roc, Sumin, and Chanbin — do you have any thoughts on the testing plan, or any
other considerations to share?
Thanks,
Chanhae Oh
> 2026. 6. 27. 오후 7:43, Yuepeng Pan <[email protected]> 작성:
>
> Hi, Ferenc,
>
> Thank you very much for the detailed explanation and additional context.
>
>> If there are no actual compatibility
>> issues in the JDBC connector (I'm not sure, cause I am not really familiar
> with
>> the code itself, but based on my own experience, I doubt)
>
> In my limited reading, This may be largely a retrospective question,
> and arriving at a precise conclusion in advance is challenging.
>
> And please let me to summarize and simplify this as much as possible—your
> suggestion is essentially to publish only two versions along these lines,
> v3.4.0 for the 1.20.x series
> v4.1.0 for the 2.x series
>
> Hope I get your meaning.
>
> Thanks,
> Yuepeng Pan
>
> Ferenc Csaky <[email protected]> 于2026年6月27日周六 03:58写道:
>
>> Do we have specific backward compatibility risks in this case?
>>
>> The connector dev docs [1] have guidance about Flink version support, and
>> the
>> goal is to support the latest 2 minor Flink version. Ofc, if there is
>> demand, it
>> makes sense to support or release for older versions, but in this case I
>> feel
>> there is no real reason to do separate major versions for 2.1 and 2.2.
>>
>> Especially that most connectors now are using the Source and Sink APIs, so
>> technically it mostly should just work with newer Flink versions. For
>> example I
>> am using the 4.0.1-2.0 Kafka connector and 4.0.0-2.0 JDBC connector with
>> Flink
>> 2.2 without any problems since 2.2 was released.
>>
>> (And I guess pretty much everybody else, who does not have their own fork
>> and
>> connector releases.)
>>
>> Connector maintenance is a pain point in general and most of them are
>> lagging
>> behind Flink versions. Getting a JDBC connector release for 2.2 was
>> discussed
>> 4,5 months ago [2]. So I do not think it would be a good idea to introduce
>> new major connector versions and increase the support burden further unless
>> there is a very good reason to do so. If there are no actual compatibility
>> issues in the JDBC connector (I'm not sure, cause I am not really familiar
>> with
>> the code itself, but based on my own experience, I doubt), I am -1 on
>> v5.0.0-2.1
>> and v6.0.0-2.2.
>>
>> Instead, I would suggest a 5.0.0-2.1 and 5.0.0-2.2. Or, if on the JDBC-side
>> there is no backward-incompatible feature shipped since 4.0.0, then
>> 4.1.0-2.1 and 4.1.0-2.2 would be even better, cause then the 4.0.0 reaches
>> EoL.
>>
>> Best,
>> Ferenc
>>
>> [1]
>> https://cwiki.apache.org/confluence/spaces/FLINK/pages/231116690/Externalized+Connector+development#ExternalizedConnectordevelopment-Support
>> [2] https://lists.apache.org/thread/o6gpkwlcyk5qf933mqd0fq9fo58hx21t
>>
>>
>>> On Thursday, June 25th, 2026 at 16:57, Yuepeng Pan <[email protected]>
>>> wrote:
>>>
>>> Hi, Ferenc Csaky.
>>>
>>> Thanks so much for your feedback.
>>>
>>> Attached[1] is our earlier discussion on version numbering—it might help
>>> clarify part
>>> of your question and provide some historical context around this release.
>>> The email[1] focuses primarily on version naming and continuity,
>>> rather than compatibility (likely because maintaining sequential
>>> version numbers mitigates most backward-compatibility risks).
>>>
>>> [1]https://lists.apache.org/thread/4jr8h98qr67l9wx8770sq8c0r44zpk1y
>>>
>>> Best regards,
>>> Yuepeng Pan
>>>
>>>
>>> Ferenc Csaky <[email protected]> 于2026年6月25日周四 22:41写道:
>>>
>>>> Hi,
>>>>
>>>> Thanks for driving this!
>>>>
>>>> I see that every Flink minor version will have a major connector
>> version.
>>>> Do we
>>>> have any specific reason to do so? The different versions ship
>> backward-
>>>> incompatible changes between those Flink versions? Otherwise I do not
>> see a
>>>> reason to do this, that's why I'm asking.
>>>>
>>>> Best,
>>>> Ferenc
>>>>
>>>>
>>>>
>>>> On Thursday, June 25th, 2026 at 02:52, 주수민 <[email protected]>
>> wrote:
>>>>
>>>>> Hi Dev,
>>>>>
>>>>> This is a progress update and plan sync for the upcoming
>>>>> flink-connector-jdbc releases
>>>>> targeting the following versions:
>>>>>
>>>>> [1] jdbc-3.4.0 (for Flink 1.20)
>>>>> [2] jdbc-5.0.0 (for Flink 2.1)
>>>>> [3] jdbc-6.0.0 (for Flink 2.2)
>>>>>
>>>>> We have reviewed and merged critical, high-priority PRs, and we are
>> now
>>>>> moving forward
>>>>> to build the RC (Release Candidate) in the next phase.
>>>>>
>>>>> [Progress]
>>>>>
>>>>> 1. Jira version tags have been created (jdbc-3.4.0, jdbc-3.5.0,
>>>>> jdbc-5.0.0, jdbc-6.0.0).
>>>>> Note: jdbc-3.5.0 is prepared as a reserve version to accommodate
>>>>> potential follow-up
>>>>> patches after the initial jdbc-3.4.0 release, if needed.
>>>>> 2. The major feature patch (PR #180 [4]) has been merged.
>>>>> 3. PR #198 [5] was submitted as a follow-up to the stale PR
>> #174[6]
>>>>> (FLINK-38046).
>>>>>
>>>>> [1]
>>>>>
>>>>
>> https://issues.apache.org/jira/browse/FLINK-33463?jql=project%20%3D%20FLINK%20AND%20fixVersion%20%3D%20jdbc-3.4.0
>>>>> [2]
>>>>>
>>>>
>> https://issues.apache.org/jira/browse/FLINK-33463?jql=project%20%3D%20FLINK%20AND%20fixVersion%20%3D%20jdbc-5.0.0
>>>>> [3]
>>>>>
>>>>
>> https://issues.apache.org/jira/browse/FLINK-39974?jql=project%20%3D%20FLINK%20AND%20fixVersion%20%3D%20jdbc-6.0.0
>>>>> [4] https://github.com/apache/flink-connector-jdbc/pull/180
>>>>> [5] https://github.com/apache/flink-connector-jdbc/pull/198
>>>>> [6] https://github.com/apache/flink-connector-jdbc/pull/174
>>>>>
>>>>> Thanks,
>>>>> Sumin Joo
>>>>>
>>>>
>>>
>>