Hi all, This is a tough topic, I also had to write things down a couple of times. To summarize and add my thoughts:
a) I think everyone is agreeing that "Only the last 2 versions of a connector are supported per supported Flink version, with only the latest version receiving new features". In the current situation, that means that Flink 1.14 and Flink 1.15 would be supported for connectors. This results in a maximum of 4 supported connector versions. b1) In an ideal world, I would have liked Flink's APIs that are used by connectors to be versioned (that's why there's now a Sink V1 and a Sink V2). However, we're not there yet. b2) With regards to the remark of using @Interal APIs, one thing that we agreed to in previous discussions is that connectors shouldn't need to rely on @Interal APIs so that the connector surface also stabilizes. b3) In the end, I think what matters the most is the user's perception on versioning. So the first thing to establish would be the versioning for connectors itself. So you would indeed have a <major.minor.patch> scheme. Next is the compatibility of that scheme with a version of Flink. I do like Chesnay's approach for using the Scala suffixes idea. So you would have <major.minor.patch connector>_<major.minor Flink version>. In the currently externalized Elasticsearch connector, we would end up with 3.0.0_1.14 and 3.0.0_1.15 as first released versions. If a new Flink version would be released that doesn't require code changes to the connector, the released version would be 3.0.0_1.16. That means that there have been no connector code changes (no patches, no new features) when comparing this across different Flink versions. b4) Now using the example that Chesnay provided (yet slightly modified to match it with the Elasticsearch example I've used above), there exists an Elasticsearch connector 3.0.0_1.15. Now in Flink 1.16, there's a new API that we want to use, which is a test util. It would result in version 3.1.0_1.16 for the new Flink version. Like Chesnay said, for the sake of argument, at the same time we also had some pending changes for the 1.15 connector (let's say exclusive to 1.15; some workaround for a bug or smth), so we would also end up with 3.1.0-1.15. I agree with Danny that we should avoid this situation: the perception of the user would be that there's no divergence between the 3.1.0 version, except the compatible Flink version. I really am wondering how often we will run in that situation. From what I've seen so far with connectors is that bug fixes always end up in both the release branch and the master branch. The only exceptions are test stabilities or documentation fixes, but if we only resolve these, they wouldn't need to be released. If such a special occasion would occur, I would be inclined to go for a hotfix approach, where you would end up with 3.0.0.1_1.15. c) Branch wise, I think we should end up with <major.minor.patch connector>_<major.minor Flink version>. So again the Elasticsearch example, at this moment there would be 3.0.0_1.14 and 3.0.0_1.15 branches. Best regards, Martijn
