Conversation
Every broker interaction stays with Flink's connector, so the connector release a line is built against decides what Kafka behaviour and fixes that line can ever receive. On the older line that release targets a different patch version than the engine does and is the last one its maintainers published, which is a support boundary a deployment needs stated rather than inferred from a version table. Name the admitted pairing on the connector page alongside the client it was built against, say how it is exercised on every change, and note that a newer Kafka connector now requires a newer host line. Point the compatibility page at it instead of repeating the detail.
|
@jordepic, pinging for a review just some doc updates and making sure docs are accurate |
jordepic
left a comment
jordepic
left a comment
There was a problem hiding this comment.
The release/client version table matches the build pins, and all 47 checks passed. One correction is needed in the new validation claim before this documentation is ready to merge.
| `streamfusion-kafka` module suite under `-Pflink-1.18`, and by Flink's own unchanged | ||
| `DynamicKafkaTableITCase`, `KafkaChangelogTableITCase`, `KafkaTableITCase` and | ||
| `UpsertKafkaTableITCase` running against real brokers in the upstream `kafka` suite on the 1.18 | ||
| line. Both prove native execution rather than only passing. |
There was a problem hiding this comment.
[P2] Describe the actual Flink 1.18 Kafka validation. This paragraph includes DynamicKafkaTableITCase in the 1.18 suite and says both suites prove native execution. However, docs/upstream-flink-suite.md at this same commit explicitly records that Kafka 3.2 / Flink 1.18 contains only the changelog, table and upsert classes, that DynamicKafkaTableITCase belongs to the newer suite, and that Kafka invocations do not yet have individual native-route contracts. Please list the three available 1.18 classes and distinguish suite success from the native-execution evidence actually asserted, rather than claiming the missing class/route coverage.
2 participants
Every broker interaction stays with Flink's connector, so the connector release a line is built against decides what Kafka behaviour and fixes that line can ever receive. On the older line that release targets a different patch version than the engine does and is the last one its maintainers published, which is a support boundary a deployment needs stated rather than inferred from a version table.
Name the admitted pairing on the connector page alongside the client it was built against, say how it is exercised on every change, and note that a newer Kafka connector now requires a newer host line. Point the compatibility page at it instead of repeating the detail.