Thanks Ismael. Sounds like a good idea to split the specific 4.0
question and the long term policy.
For 4.0, it's a little tricky and could be confusing for users no matter
what we do.
- If only support 2.1+ to 4.0 client/KS upgrade, it's a weird cut-off
version
- If we support 2.0+ to 4.0 client/KS upgrade it's simpler, but of
course brokers cannot be 4.0 yet -- but I guess this would be something
natural? Given that the clients would be on 2.0, brokers cannot be 4.0
yet, or clients would have crashed already... Thus, I think I slightly
prefer this one.
I think it's fine to drop testing upgrading client/KS from
0.10/0.11/1.x. These version are very old, and thus API compatibility is
not guaranteed any longer...
For KS, from an API compatibility POV, upgrading from anything older
than 3.6 might not work any longer (for DSL users; of course, depending
on what APIs they are using). And for PAPI, the old API was removed too,
so only if the new one is use (introduced in 2.7) a seamless upgrade
would work smoothly.
-Matthias
On 1/20/25 11:27 AM, Chia-Ping Tsai wrote:
Juma made a valid point in the Jira ticket: "we cannot change the client upgrade guarantees
outside of a major release." To avoid blocking the 4.0 release, this thread should focus on
the "client upgrade path." We can create a separate ticket to discuss the advanced
compatibility policy.
Additionally, we need to upgrade e2e (and docs) according to the client upgrade
path
Best,
Chia-Ping
On 2025/01/20 18:04:43 Chia-Ping Tsai wrote:
To Kuan-Po
When we're talking about two major versions, should it be [4.x, 5.x] or
[4.x, 6.x]? The latter seems to refer to three major versions, doesn't it?"
Sorry for the unclear description. My point is that 5.x can communicate
with both 4.x and 6.x.
In the meantime, I think we should align on the plan for 4.0. Do we really
want to keep testing and supporting direct client upgrades from 0.11 to
4.0? Is that even a good idea? Seems pretty risky to me.
The upgrade paths described by KIP-1124 do not include 0.11 -> 4.0
*Propose documenting the following recommended upgrade path: *
*Kafka Client: [0.11.x - 1.x] → [2.0.x - 3.9.x] → 4.x*
*Kafka Streams: [0.11.x - 2.3.x] → [2.4.x - 3.9.x] → 4.x*
*Best,*
*Chia-Ping*
Ismael Juma <m...@ismaeljuma.com> 於 2025年1月21日 週二 上午1:22寫道：
Thanks for the KIP - one suggestion I have is to perhaps separate the long
term policy (which will naturally require a lot more debate) and what we
plan to do for 4.0.
Why is the long term policy more complicated? Because it is trying to
predict the future (Matthias made a comment regarding how 2.x and 3.x were
long release lines for example, but we don't actually know how long 4.x or
5.x will be). It's a worthwhile discussion, but shouldn't be rushed.
In the meantime, I think we should align on the plan for 4.0. Do we really
want to keep testing and supporting direct client upgrades from 0.11 to
4.0? Is that even a good idea? Seems pretty risky to me.
Ismael
On Wed, Jan 15, 2025, 5:45 AM Kuan Po Tseng <brandb...@gmail.com> wrote:
Hi all,
I'd like to initiate a discussion thread on *KIP-1124,* which proposes a
clear upgrade path for Kafka Client, including Kafka Streams.
You can find the details here:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1124%3A+Providing+a+clear+Kafka+Client+upgrade+path
I’d appreciate it if you could take a look and share your thoughts or
feedback.
Best regards,
Kuan-Po Tseng
