mjsax commented on PR #18193: URL: https://github.com/apache/kafka/pull/18193#issuecomment-2571390278
> KIP-896 has explicitly defined version 2.1 as the baseline version I don't really think that KIP-896 is in the center, as it defines broker-client cross-version compatibility, while we are discussing KS upgrade compatibility... This is two different things IMHO. If I have a 2.1+ broker, I can run a 2.0, 1.x, or 0.11.x KS application and upgrade it to 4.0 directly. KIP-896 only defines 2.1 as baseline _client version_ for a broker upgrade to 4.0+. It does not say anything about client/KS upgrades. Thus, we should not mix both dimension (broker upgrade vs client upgrade) but discuss them independently IMHO. Thus, following `[0.7 - 2.0] -> [2.1 - 3.9] -> 4.0+` proposal is somewhat weird from a KS upgrade POV... It's confusing why 2.0 would be in the first bucket, but not in the second one... I would rather go with `[0.11.x - 1.x] -> [2.0 - 3.9] -> 4.x`. Note that I changed lowest version to 0.11.x as we did have some KS breaking changes in 0.10.x releases (and there was no KS before 0.10.0.0 anyway), and also changed from `4.0+` to `4.x` to exclude `5.x` on purpose, so we can prepare to cut down upgrade guarantees to two major versions only. I think supporting upgrade between 3 major versions is something we should drop mid/long term. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
