Hi devs, I'd like to correct my previous email regarding the version tags.
The correct version tags should be as follows: Primary releases: - jdbc-3.4.0 (for Flink 1.20.x) - jdbc-5.0.0 (for Flink 2.1.x) - jdbc-6.0.0 (for Flink 2.2.x) Reserve tags (in case additional patch releases are needed): - jdbc-3.5.0 (for Flink 1.20.x) - jdbc-5.1.0 (for Flink 2.1.x) - jdbc-6.1.0 (for Flink 2.2.x) Sorry for any confusion caused by my previous email. Thank you in advance for your support! Best regards, ChanHae Oh > 2026. 6. 18. 오후 7:18, Chanhae Oh <[email protected]> 작성: > > > Hi devs, > > Following up on this discussion, as we are now moving forward with the > release plan, we would like to request the creation of the following Jira > version tags for ticket management: > > Primary releases: > - jdbc-3.5.0 (for Flink 1.20.x) > - jdbc-5.0.0 (for Flink 2.1.x) > - jdbc-6.0.0 (for Flink 2.2.x) > > Reserve tags (in case additional patch releases are needed): > - jdbc-5.1.0 (for Flink 2.1.x) > - jdbc-6.1.0 (for Flink 2.2.x) > > Could a PMC member or someone with the necessary Jira administrator > permissions help create these version tags? > > Thank you in advance for your support! > > Best regards, > ChanHae Oh > >> 2026. 6. 16. 오전 11:00, 오찬빈 <[email protected]> 작성: >> >> Hi Yuepeng and Devs, >> >> Thanks Yuepeng for driving this discussion and volunteering as the RM. >> >> I agree with Rui and Chanhae's points regarding the versioning strategy. >> Referring to how Kafka or other external connectors manage their versions >> (e.g., {Connector Version}-{Flink Version} or clear cross-reference) would >> definitely improve user clarity in the long run. >> >> For the upcoming release, continuing with the existing sequential scheme to >> avoid disruption while aligning on a unified convention for future roadmap >> items seems like a pragmatic approach. >> >> Also, I agree that dropping support for Flink 2.0 makes sense, as focusing >>> on the Flink 1.20 (LTS) and the latest 2.x lines will provide more value to >>> the community. >>> >>> Best regards, >>> ChanBin Oh >>> >>> 2026년 6월 16일 (화) 오전 9:47, Chanhae Oh <[email protected]>님이 작성: >>> >>> >>> 나의 iPhone에서 보냄 >>> >>> 전달된 메시지 시작: >>> >>> *보낸 사람:* Yuepeng Pan <[email protected]> >>> *날짜:* 2026년 6월 15일 오후 11시 2분 23초 GMT+9 >>> *받는 사람:* [email protected] >>> *제목:* *Re: [DISCUSS] Release Plan for the Next Group of Flink JDBC >>> Connector Versions* >>> *답장 받을 사람:* [email protected] >>> >>> Thanks Chanhae, Sumin for the comments, Rui for the clarification. >>> >>> After reviewing the Kafka connector release lineage and current status, >>> IIUC, we'd plan to roll out *v5.0 (targeting Flink 2.1)* and *v3.4 >>> (targeting Flink 1.20)*. >>> >>> Welcome *Chanhae* and *Sumin* to this release cycle! >>> >>> Looking forward to more feedback! >>> >>> Best regards, >>> Yuepeng Pan >>> >>> Rui Fan <[email protected]> 于2026年6月15日周一 18:26写道： >>> >>> Thanks Yuepeng for driving the release! >>> >>> >>> About Versioning Strategy, we could refer to the release of Kafka or other >>> >>> connectors. >>> >>> >>> Best, >>> >>> Rui >>> >>> >>>> On Fri, Jun 12, 2026 at 12:26 PM 주수민 <[email protected]> wrote: >>> >>> >>> Hi Yuepeng, >>> >>> >>> Thank you for initiating this discussion. >>> >>> >>> Personally, I agree with Chanhae's thoughts on the versioning strategy >>> >>> and >>> >>> focusing on the Flink 1.20 (LTS) / 2.x lines. >>> >>> I would love to participate in this release effort and help out if my >>> >>> contribution is welcome. >>> >>> >>> Thank you again for driving this forward! >>> >>> >>> Best regards, >>> >>> Sumin Joo >>> >>> >>> 2026년 6월 9일 (화) 오전 11:56, Chanhae Oh <[email protected]>님이 작성: >>> >>> >>> Hi Yuepeng, >>> >>> >>> Thank you for starting this discussion. I'd like to share my thoughts >>> >>> on >>> >>> the topics you raised. >>> >>> >>> --- >>> >>> >>> *1. Versioning Strategy for Flink 2.1, 2.2, and 2.3* >>> >>> >>> A versioning scheme such as {Connector Version}-{Flink Version}, >>> >>> similar >>> >>> to >>> >>> what users often see in Maven repositories, would provide better >>> >>> clarity >>> >>> and consistency. >>> >>> However, I think it would be even more beneficial if such a convention >>> >>> were >>> >>> adopted consistently across other connector repositories as well. >>> >>> For the next release, I would prefer to continue with the existing >>> >>> sequential versioning scheme to minimize disruption. >>> >>> At the same time, it may be worth discussing a coordinated naming >>> >>> convention across connector repositories for future releases. >>> >>> >>> >>> *2. Support Policy for Flink 2.0* >>> >>> >>> Personally, I don't think continued support for Flink 2.0 is >>> >>> particularly >>> >>> necessary. >>> >>> Many improvements and new features have already been introduced in >>> >>> later >>> >>> Flink releases. >>> >>> Additionally, when comparing the user bases of Flink 1.20 and Flink >>> >>> 2.0, >>> >>> I >>> >>> would expect the Flink 1.20 (LTS) line to have broader adoption and >>> >>> remain >>> >>> more important for long-term support. >>> >>> >>> --- >>> >>> >>> Also, if there is anything I can help with for the upcoming release >>> >>> effort, >>> >>> I would be happy to contribute and support the work as much as I can. >>> >>> >>> Best regards, >>> >>> Chanhae Oh >>> >>> >>> On Tue, Jun 9, 2026 at 1:24 AM Yuepeng Pan <[email protected]> >>> >>> wrote: >>> >>> >>> Hi Devs, >>> >>> >>> Following the release of v3.3 (for Flink 1.20.x) and v4.0 (for Flink >>> >>> 2.0.x), the Flink JDBC Connector has not had a new release for quite >>> >>> some >>> >>> time. During this period, Flink itself has released versions 2.1, >>> >>> 2.2, >>> >>> and >>> >>> 2.3 (upcoming). >>> >>> >>> I would like to initiate a discussion regarding the next group of >>> >>> Flink >>> >>> JDBC Connector releases. >>> >>> >>> 0. I’d like to hear more thoughts on the next release >>> >>> >>> >>> Based on a quick review of the current repository status, I have >>> >>> identified >>> >>> several topics that need to be discussed before the release plan: >>> >>> >>> >>> 1. Versioning Strategy for Flink 2.1, 2.2, and 2.3 >>> >>> Do we need a new branching/versioning scheme to maintain patches and >>> >>> updates for these specific Flink versions? >>> >>> >>> Option A: Semantic versioning tied to Flink (e.g., v2.1-1.0) >>> >>> Format: {Flink_Version}-{Connector_Version}(e.g., 2.1-1.0). >>> >>> Pros: It is immediately clear which Flink version the connector >>> >>> supports. >>> >>> Cons: This deviates from our historical naming convention and might >>> >>> cause >>> >>> confusion for users and developers. >>> >>> >>> Option B: Continuing sequential versioning (e.g., v5.x, v6.x) >>> >>> Mapping: v5.xfor Flink 2.1, v6.xfor Flink 2.2, etc. >>> >>> Pros: Consistent with the previous naming scheme (v3.x, v4.x). >>> >>> Cons: It is less intuitive to map connector versions to Flink >>> >>> versions. >>> >>> >>> >>> Note on LTS: Regardless of the outcome for the 2.x series, continuing >>> >>> to >>> >>> use the v3.xseries for the long-term support (LTS) Flink 1.20.x line >>> >>> may >>> >>> remain a solid choice. >>> >>> >>> >>> 2. Support Policy for Flink 2.0 >>> >>> Do we still need to support the JDBC connector for Flink 2.0? Since >>> >>> the >>> >>> latest Flink version is 2.3 (upcoming), Flink 2.0 is now three minor >>> >>> versions behind. >>> >>> >>> >>> BTW, I'd be willing to volunteer as a Release Manager (RM) for the >>> >>> next >>> >>> release of Flink JDBC connector. >>> >>> I also look forward to collaborating with other interested >>> >>> contributors >>> >>> to >>> >>> drive this effort forward. >>> >>> >>> >>> Thank you very much. And looking forward to your feedback. >>> >>> >>> >>> Best regards, >>> >>> Yuepeng Pan >>> >>> >>> >>> >>> >>>
