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
>
