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




Reply via email to