I personally think we should just recommend 3.9 as the sole bridge release, and not include 2.8. Major versions are about API compatibility, there shouldn't be any inherent risk in upgrading more than one major release at a time. Things are already complicated enough :)
I do agree that we should just lay out a specific version to recommend for a bridge release rather than trying to include the range of all possible bridge versions. I also think we should make a separate section in the Streams upgrade guide specifically about when and why the `upgrade.from` config & double rolling bounce is needed. Then we can just link to that in the KIP and don't have to get into the weeds too much. I won't be able to put this together until mid next week at the earliest but maybe Matthias will have time for it before that? So for Kafka Streams this KIP should basically just state two things: users upgrading from 2.3 or below need to first upgrade to 3.9 then to 4.0, and they should refer to the upgrade guide (specifically the `upgrade.from` section we'll add soon) for specific instructions regarding the first upgrade to 3.9 Side question: do we need to call out that the rows are not mutually > exclusive, but cumulative? Ie, if one is on 2.2 with EOSv1 enabled, two > row apply: need to switch from eager to cooperative rebalancing, and > need to switch from EOVv1 to EOSv2. -- Or is this clear anyway? Lastly, was just thinking about the EOS thing, and I realize I don't understand why we have to treat this specially or outline a different upgrade path. It's the same as any other API change from upgrading across major versions, right? For example: if you try to upgrade an EOSv1 app (let's say 2.4) to 4.0, you get a compiler error, and change to the new config. You just need to update your source code, it's not like you can't do that upgrade or have to go through a bridge release. At most you need to make sure the brokers are 2.5 or above but that's not what this table is about On Wed, Feb 26, 2025 at 8:12 AM Kuan Po Tseng <brandb...@apache.org> wrote: > Hi Matthias, > > I appreciate your feedback; it really helped me a lot! > Regarding the issue of upgrading streams from a very old version to 4.x, > I understand that streams are much more complicated than Kafka Client. > I think it's reasonable to do two bumps, but I'm not a Kafka Streams > expert, > and I would like to hear others' opinions as well. > > I just updated the KIP, and I hope I have addressed all your comments > above. > Please let me know if I missed anything. > > Best, > Kuan-Po Tseng > > On 2025/02/25 03:32:06 "Matthias J. Sax" wrote: > > Thanks all. Seems we are converging. :) > > > > Again, sorry to the previous very long email, but I thought it's > > important to paint a full end-to-end picture. > > > > I agree that we should try to keep it simple to the extend reasonable > > possible! If we really want to suggest just 2.8 / 3.9 as bridge > > versions, I am ok with this. > > > > About upgrades across multiple major version. Yes, it's certainly > > possible for some simple apps, and if we want to keep the guidelines > > simple, we can also drop 2.8 as bridge release and only use 3.9. My take > > was just, that it seems to de-risk an upgrade to not recommend skipping > > a major release; but I can be convinced otherwise :) > > > > Guess it would simplify the table, and we could cut one column. Let's > > hear from Sophie again about it. > > > > > > > > For the rows in the table: > > > > > Kafka Streams > > > 0.11.x - 2.3.x > > > > It says > > > > > No, you'll need to do two-rolling bounce twice. > > > > I don't think that "two-rolling bounce twice" is necessary, and it might > > be simpler to be less details on the KIP anyway, but refer to the docs? > > Similar for other rows... if a two-rolling bounce is necessary, is a "it > > depends" answer in many cases, and just omitting it in this table might > > be easier. > > > > Instead, it might be good to call out, what needs to be upgraded though, > > ie, need to upgrade from "eager" to "cooperative" rebalancing if old > > version is 0.11 to 2.3. Similar to what we already say for: > > > > > Kafka Streams > > > 2.4.x - 3.9.x with EOSv1 > > > > when we call out EOSv1 is removed with 4.0. > > > > > > > > Side question: do we need to call out that the rows are not mutually > > exclusive, but cumulative? Ie, if one is on 2.2 with EOSv1 enabled, two > > row apply: need to switch from eager to cooperative rebalancing, and > > need to switch from EOVv1 to EOSv2. -- Or is this clear anyway? > > > > > > > > > Since Kafka Streams 2.4.0 introduced cooperative rebalancing, which is > enabled by default, it is no longer possible to directly upgrade a Streams > application from a version prior to 2.4 to 2.4 or higher. > > > > "which is enabled by default" is not really the reason why the upgrade > > from 2.3 (and earlier) to 4.0 breaks. The reason is, that "eager" > > support is dropped with 4.0. > > > > > > > > > > -Matthias > > > > > > On 2/24/25 8:28 AM, Kuan Po Tseng wrote: > > > Hello everyone, > > > > > > Thanks Chia-Ping for the advice. I’ve created a table to cover all > upgrade path scenarios, hoping it provides more clarity. Please let me know > if I’ve misunderstood anything. I appreciate any corrections! > > > > > > Additionally, as I recently updated the KIP title, here’s the new link: > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1124%3A+Providing+a+clear+Kafka+Client+upgrade+path+for+4.x > > > > > > Regarding Kafka Connect, I’m still investigating and will update the > KIP soon. I’ll share any new findings with you as soon as possible. > > > > > > Thank you! > > > > > > Best, > > > Kuan-Po > > > > > > On 2025/02/23 19:12:41 Chia-Ping Tsai wrote: > > >> hi Kuan-Po > > >> > > >>> Apologies for my mistake... Indeed, 2.1 should be the starting point > for the bridge version. > > >> > > >> Have you updated the KIP? it seems the bridge version of client still > starts from 2.0 > > >> > > >> Additionally, if I were a user hesitant to adopt the bridge version, > it would be helpful to list common reasons to aid in choosing the "best" > bridge version. For example: > > >> > > >> Client Upgrade Paths > > >> > > >> // here is the table > > >> > > >> Best Bridge Version to you > > >> > > >> // add some explanation > > >> > > >> 1. minimize code refactoring - // Kafka Client: 3.3.x - 3.9.x + Kafka > Streams: 3.6.x - 3.9.x > > >> 2. starts with quorum APIs - // 3.3.x - 3.9.x > > >> 3. xxx > > >> 4. aaa > > >> n. last stable/active version: 3.9.x // we can emphasize the 3.9 is > recommended by community > > >> > > >> Best, > > >> Chia-Ping > > >> > > >> > > >> > > >> On 2025/02/23 16:10:03 Kuan Po Tseng wrote: > > >>> Thanks, Jun and Juma, > > >>> > > >>> Apologies for my mistake... Indeed, 2.1 should be the starting point > for the bridge version. > > >>> I will revise my statement as follows: > > >>> - For Kafka Clients below 2.1, users need to upgrade to 3.9 first, > then to 4.x. > > >>> - For Kafka Clients from 2.1 or above, users can directly upgrade to > 4.x. > > >>> > > >>> As for Kafka Connect, I initially didn’t consider it because I saw > it as another form of a server. > > >>> However, I’m not very familiar with this area and will need some > time to look into it. > > >>> > > >>> --- > > >>> > > >>> Thanks, Matthias and Sophie, for the detailed explanation. > > >>> > > >>> The Streams upgrade is indeed complex... I took some time to digest > these details. > > >>> It sounds like the key concerns for the Streams upgrade are: > > >>> 1. Users still using EOSv1 > > >>> 2. Users relying on Eager rebalancing (i.e., versions before 2.4) > > >>> > > >>> With this in mind, should we adjust the recommended upgrade path to > the following? > > >>> - For Kafka Streams below 2.4, you’ll need to first upgrade to 2.8, > then to 3.9, and finally to 4.x. > > >>> - For Kafka Streams using EOSv1 on versions 2.4 or above, you’ll > need to upgrade to 3.9 first, then to 4.x. > > >>> - Others can directly upgrade to 4.x. > > >>> *Note*: If upgrading Streams from 3.4 or below, you’ll need to > perform two rolling bounces. > > >>> For more details, please refer to: [Kafka Streams Upgrade Guide]( > https://kafka.apache.org/39/documentation/streams/upgrade-guide). > > >>> Also, Kafka Streams requires broker compatibility considerations, > see: [Streams API Broker Compatibility]( > https://kafka.apache.org/39/documentation/streams/upgrade-guide#streams_api_broker_compat > ) > > >>> > > >>> The above approach simplifies the definition of the bridge version. > > >>> Instead of providing a range (e.g., [3.5-3.9]), would it be better > to specify 3.9 directly to > > >>> reduce users' decision anxiety? This aligns with Juma’s > recommendation for bridge versions > > >>> in the Kafka Clients upgrade. 3.9 is the last version before 4.0, > > >>> containing the most bug fixes and offering greater stability. > > >>> For detailed upgrade steps, such as two-rolling bounce upgrades, > > >>> like Matthias recommended we should direct users to the Streams > upgrade documentation. > > >>> And I feel the examples in my KIP are too simplistic, > > >>> but I don’t think I should make them as detailed as the Streams > upgrade guide. > > >>> Otherwise, I’d just be duplicating content. The goal of this KIP > should be to provide > > >>> users with a clear high-level upgrade path, while the detailed steps > should be > > >>> referenced from the Streams upgrade documentation. > > >>> > > >>> Regarding ALOS, it looks like we support versions from 0.11.x to 4.x, > > >>> so there’s no need to specify additional details, right? Or am I > missing something? > > >>> > > >>> Lastly, based on Matthias' suggestion, I have revised the motivation > section to emphasize: > > >>> - Simplifying testing > > >>> - Reducing compatibility challenges across too many versions > > >>> - Clearly defining the recommended upgrade paths > > >>> > > >>> Best, > > >>> Kuan-Po Tseng > > >>> > > >>> On 2025/02/21 23:55:51 Sophie Blee-Goldman wrote: > > >>>> whew, long response from Matthias :P Lot to digest but I want to add > > >>>> on/respond to a few points: > > >>>> > > >>>> If they want to be "advantageous", they could make it a two step > upgrade > > >>>>> I guess, and go from 2.5 (or older) directly to 3.x and apply all > > >>>>> required code changes in a single upgrade step, and repeat the > same to > > >>>>> upgrade to 4.0. But I would not necessarily recommend to do an > non-API > > >>>>> compatible upgrade directly, and for sure officially discourage it > for > > >>>>> two major releases. > > >>>> > > >>>> Are we still talking about only API compatibility here? Because I'm > not so > > >>>> sure why we would > > >>>> officially discourage upgrading across 2 major releases as long as > their > > >>>> code is compatible. Of > > >>>> course if you're referring to possible gotchas from upgrading over > such a > > >>>> long period, that's worth > > >>>> discussing, but it's independent of API compatibility. Imo API > > >>>> compatibility is a binary thing: either > > >>>> it's possible to do a direct upgrade or it's not. Why do we have to > > >>>> officially recommend anything? > > >>>> > > >>>> Or we can distinguish > > >>>>> between ALOS and EOS and have an "bridge release version range" > for both > > >>>>> cases. > > >>>> > > >>>> I like this idea. EOS and ALOS are very distinct in Streams and may > only > > >>>> become moreso divided > > >>>> over time. It's worth calling them out as separate cases > > >>>> > > >>>> Now regarding the eager/cooperative rebalancing protocol thing in > Streams: > > >>>> > > >>>> As Matthias said we hope to officially drop support for eager > rebalancing > > >>>> in 4.0, and I've prepared > > >>>> a PR for this already: https://github.com/apache/kafka/pull/18988 > > >>>> > > >>>> This does have the effect of forcing a bridge release for users > hoping to > > >>>> upgrade directly from 2.3 > > >>>> or below to 4.0+, and users will have to follow a specific upgrade > path to > > >>>> do so as outlined in the > > >>>> PR description. Assuming we fit that into 4.0, it should definitely > be > > >>>> called out in this KIP. (Basically > > >>>> users need to use the `upgrade.from` config to first upgrade to the > bridge > > >>>> release, then go on to 4.0) > > >>>> > > >>>> There are also other runtime incompatibilities that have been > introduced > > >>>> into Streams over the years > > >>>> that restrict direct live upgrades across certain versions. It > would also > > >>>> be good to call this out in > > >>>> the KIP and point to the `upgrade.from` config, though we can point > to the > > >>>> Streams upgrade guide > > >>>> for details rather than try to reiterate everything here. > > >>>> > > >>>> > > >>>> On Thu, Feb 20, 2025 at 5:21 PM Matthias J. Sax <mj...@apache.org> > wrote: > > >>>> > > >>>>> Hello, > > >>>>> > > >>>>> took me some time, and sorry for the long email, but it's > complicated... > > >>>>> > > >>>>> First, I just re-read the latest version of the KIP. Thanks for > all the > > >>>>> updates. > > >>>>> > > >>>>> > > >>>>> One thing that I an missing in the motivation is, that we really > want to > > >>>>> stop support direct upgrades from older versions, to cut down our > > >>>>> upgrade matrix for testing. The motivation does somewhat touch on > it, > > >>>>> but I think it would be good to be more explicit. Even if it isn't > > >>>>> something users care about, it's a second main motivation for us, > in > > >>>>> addition to the complexity to actually keep the versions > compatible. > > >>>>> > > >>>>> > > >>>>> I also want to further clarify my understanding of the KIP. The > goal is > > >>>>> not to define what upgrades are possible, right? What is possible > is > > >>>>> much more nuanced. -- But we rather want to define what we > recommend? Is > > >>>>> this understanding correct? If yes, it might also be worth to add > to the > > >>>>> motivation section. > > >>>>> > > >>>>> > > >>>>> I also think, we actually need to more explicitly distinguish three > > >>>>> categories of compatibility, but did so far only discuss two of > them. > > >>>>> Even if the KIP does mention all three. Ideally, we should have a > > >>>>> section in the motivation, explaining the three different types of > > >>>>> compatibility, and explicitly state which one this KIP is concerned > > >>>>> with, and which ones it's not concerned with. > > >>>>> > > >>>>> > > >>>>> (1) protocol compatibility: ie, what client-broker versions are > compatible > > >>>>> > > >>>>> This one is not in the focus of the KIP, but it might still be > good to > > >>>>> be explicit about it. Could be explained in the motivation for > > >>>>> completeness, and maybe refer to KIP-896 for 4.x related changes. > > >>>>> > > >>>>> Btw: there is also some additional limitations for KS-broker > > >>>>> compatibility: > > >>>>> > > >>>>> > https://kafka.apache.org/39/documentation/streams/upgrade-guide#streams_api_broker_compat > > >>>>> > > >>>>> Many of you know this, but wanted to mention it for completeness. > Not > > >>>>> sure if we need to mention it on the KIP. > > >>>>> > > >>>>> > > >>>>> > > >>>>> (2) API compatibility (ie Java/Scala API). > > >>>>> > > >>>>> This is only mentioned briefly in the KIP, and again, it's not the > core > > >>>>> of the KIP, but I think it is still important to include it more > > >>>>> explicitly, because we talk about "bridge version". > > >>>>> > > >>>>> Given the rule that we are allowed to break API compatibility in > major > > >>>>> release, but still guarantee API compatibility for the last three > minor > > >>>>> releases, it can be confusing and it would be great to explain it > better. > > >>>>> > > >>>>> In the end, directly upgrading from 2.5 or older to 4.x is > practically > > >>>>> impossible as we went through two major releases which did remove > > >>>>> deprecated APIs, and I would not recommend to do such a direct > upgrade. > > >>>>> > > >>>>> From an API POV, if one is on 2.5 or older, they should first > upgrade > > >>>>> to 2.6/2.7/2.8, and than lazily migrate off any older stuff what is > > >>>>> removed with 3.0. Afterwards, they can upgrade to 3.7/3.8/3.9 > following > > >>>>> the same pattern, and only upgrade to 4.0 in a third step. > > >>>>> > > >>>>> If they want to be "advantageous", they could make it a two step > upgrade > > >>>>> I guess, and go from 2.5 (or older) directly to 3.x and apply all > > >>>>> required code changes in a single upgrade step, and repeat the > same to > > >>>>> upgrade to 4.0. But I would not necessarily recommend to do an > non-API > > >>>>> compatible upgrade directly, and for sure officially discourage it > for > > >>>>> two major releases. > > >>>>> > > >>>>> Thus, the information in the KIP about "bridge version" to 4.x > begin > > >>>>> "2.4.x - 3.9.x" seems to fall short, and mentioning > > >>>>> > > >>>>>> To minimize code refactoring, we recommend the following bridge > versions > > >>>>> that maintain API compatibility with Kafka 4.x: > > >>>>>> > > >>>>>> Kafka Client: 3.3.x - 3.9.x > > >>>>>> Kafka Streams: 3.6.x - 3.9.x > > >>>>> > > >>>>> seems not to be sufficient to me. > > >>>>> > > >>>>> > > >>>>> Hence, the provided "Upgrade Examples" might be oversimplified, > and we > > >>>>> might want to refine them. > > >>>>> > > >>>>> > > >>>>> > > >>>>> (3) Runtime compatibility. This one is specific to Kafka Streams, > but > > >>>>> not to clients from my understanding. Client are stateless and > thus they > > >>>>> don't face any issue, but Kafka Streams is stateful, and thus need > to > > >>>>> take care of it. Please correct me if I am wrong. > > >>>>> > > >>>>> The KIP so far, seems to only consider this one, and what is > proposed > > >>>>> make sense to me on a high level. However, I am confused why Kafka > > >>>>> Clients are mentioned here, too, as this type of compatibility > should > > >>>>> not really be relevant for them? Even if clients might also have > some > > >>>>> semantic changes, these should always align with API changes (ie, > old > > >>>>> deprecate API might have slightly different semantics than new > API). > > >>>>> > > >>>>> Now about the currently proposes ranges from Kafka Streams: > > >>>>> > > >>>>>> Kafka Streams > > >>>>>> Current Version 0.11.x - 2.3.x > > >>>>>> Bridge Release 2.4.x - 3.9.x > > >>>>>> Target Version 4.x > > >>>>> > > >>>>> This could make sense for "eager vs cooperative" rebalancing, > however, > > >>>>> at the current point, we did not remove "eager" in 4.0 yet. I was > > >>>>> actually just syncing up with Sophie about it, and it was a slip, > and we > > >>>>> want to propose to remove "eager" in 4.0 (Sophie will prepare a > PR), so > > >>>>> we can avoid keeping "eager" until 5.0. > > >>>>> > > >>>>> We did officially deprecate "eager" in 3.1 release, so we are > covered to > > >>>>> actually remove it with 4.0. > > >>>>> > > >>>>> If we would not drop "eager", using `2.4.x to 3.9.x` would not make > > >>>>> sense though. If we keep "eager" in 4.0, user can still upgrade > from > > >>>>> 2.0.x to 4.0.x w/o issues from a runtime perspective. > > >>>>> > > >>>>> If we drop "eager" we also need to drop the corresponding system > tests > > >>>>> that upgrade to 4.0, and also stop testing upgrading from "eager to > > >>>>> cooperative" with 3.9 being the highest target version in this > system > > >>>>> test. And if we don't test it, it's not officially supported any > > >>>>> longer... (even if people could still upgrade via an offline > upgrade -- > > >>>>> what really breaks if we remove "eager" is "only" the online > > >>>>> [two-]rolling bounce upgrade...) > > >>>>> > > >>>>> However, there is another change we want to consider: we did remove > > >>>>> EOSv1 in 4.0 release, which was replace with EOSv2 in Kafka > Streams 2.6 > > >>>>> via KIP-447. > > >>>>> > > >>>>> Thus, for EOSv1 users, they cannot directly upgrade to 4.0 either, > but > > >>>>> only EOSv2 users can. Thus, it might make sense to actually use > "bridge > > >>>>> releases 2.6.x - 3.9.x" just to keep it simple... Or we can > distinguish > > >>>>> between ALOS and EOS and have an "bridge release version range" > for both > > >>>>> cases. > > >>>>> > > >>>>> Btw: using EOSv2 required broker version 2.5+, that we might also > want > > >>>>> to call out. > > >>>>> > > >>>>> > > >>>>> > > >>>>> Last but not least, while we are very explicit in the KS upgrade > docs, > > >>>>> it might be worth to call out that some upgrades require a > two-rolling > > >>>>> bounce approach, and users should always consult the upgrade > docs... We > > >>>>> use two-rolling bounce upgrade to bridge runtime backward > incompatible > > >>>>> changes (similar to what we do broker side, when IBP version is > bumped). > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> So overall, it seems that we need to really have two guidelines, > not > > >>>>> just one? For for API compatibility, which is much stricter, and > one for > > >>>>> runtime compatibility? > > >>>>> > > >>>>> If we really want to make a recommendation that is most easy to > > >>>>> understand, we might want to only go with API compatibility. Not > sure if > > >>>>> this might be "too restrictive" though? > > >>>>> > > >>>>> > > >>>>> Curious to get you though on all this. > > >>>>> > > >>>>> > > >>>>> -Matthias > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> On 2/19/25 5:51 PM, Kuan Po Tseng wrote: > > >>>>>> Hi Lianet, > > >>>>>> > > >>>>>> Thank you for your feedback! > > >>>>>> > > >>>>>> Yes, the current KIP focuses solely on the client upgrade for > 4.x. I > > >>>>> have updated the title accordingly and also included the KS > upgrade link in > > >>>>> the KIP. > > >>>>>> > > >>>>>> Thanks again! > > >>>>>> > > >>>>>> Best regards, > > >>>>>> Kuan-Po > > >>>>>> > > >>>>>> On 2025/02/19 16:59:25 "Lianet M." wrote: > > >>>>>>> Hello all, sorry a bit late, just minor comments on this one: > > >>>>>>> > > >>>>>>> - Should we clarify in the title or at the beginning of the KIP > that it > > >>>>> is > > >>>>>>> proposing a client upgrade path for 4.x? The broader > considerations for > > >>>>>>> upgrades discussed in this thread will be tackled separately > (seems we > > >>>>> all > > >>>>>>> agree). > > >>>>>>> > > >>>>>>> - The KS upgrade path seems to be the tricky one, and all that > the user > > >>>>>>> needs to consider to successfully follow the provided path for > KS is not > > >>>>>>> clear in the KIP, but it's all well explained on the KS upgrade > notes > > >>>>> for > > >>>>>>> 3.9, should we add a ref to that? > > >>>>>>> https://kafka.apache.org/39/documentation/streams/upgrade-guide > > >>>>>>> > > >>>>>>> Thanks Kuan Po! > > >>>>>>> > > >>>>>>> Lianet > > >>>>>>> > > >>>>>>> On Tue, Feb 11, 2025 at 11:22 AM Kuan Po Tseng < > brandb...@gmail.com> > > >>>>> wrote: > > >>>>>>> > > >>>>>>>> Hello everyone, > > >>>>>>>> > > >>>>>>>> If there are no other opinions, I would like to start a vote > tomorrow, > > >>>>>>>> thank you! > > >>>>>>>> > > >>>>>>>> Best, > > >>>>>>>> Kuan Po > > >>>>>>>> > > >>>>>>>> On Sat, Feb 8, 2025 at 1:51 AM Kuan Po Tseng < > brandb...@apache.org> > > >>>>> wrote: > > >>>>>>>> > > >>>>>>>>> Hi all, > > >>>>>>>>> > > >>>>>>>>> Based on our discussion, I added a section on choosing the > appropriate > > >>>>>>>>> bridge version from an API compatibility perspective for > upgrading to > > >>>>>>>> Kafka > > >>>>>>>>> 4.0. Let me know if you have any thoughts. Thank you! > > >>>>>>>>> > > >>>>>>>>> Best, > > >>>>>>>>> Kuan-Po > > >>>>>>>>> > > >>>>>>>>> On 2025/02/07 03:34:46 Kuan Po Tseng wrote: > > >>>>>>>>>> Hi Chia-Ping, > > >>>>>>>>>> > > >>>>>>>>>> Sorry for the delayed response. I’ve checked all relevant > JIRAs using > > >>>>>>>>> the following Jira Query Language: > > >>>>>>>>>> > > >>>>>>>>>> project = KAFKA AND status in (Resolved, Closed) AND > fixVersion = > > >>>>> 4.0.0 > > >>>>>>>>> AND text ~ "Remove" order by updated DESC > > >>>>>>>>>> > > >>>>>>>>>> Based on this, I checked the JIRAs related to removing > deprecated > > >>>>>>>>> methods in client modules. The minimum backward-compatible > client > > >>>>>>>> versions > > >>>>>>>>> for client 4.0 are as follows: > > >>>>>>>>>> - Producer: 3.3.0 > > >>>>>>>>>> Reason: Partitioner#onNewBatch was deprecated in 3.3.0, > and was > > >>>>>>>>> removed by https://issues.apache.org/jira/browse/KAFKA-18295 > > >>>>>>>>>> - Consumer: 2.4.0 > > >>>>>>>>>> Reason: Consumer#committed was deprecated in 2.4.0, and > was > > >>>>> removed > > >>>>>>>> by > > >>>>>>>>> https://issues.apache.org/jira/browse/KAFKA-17451 > > >>>>>>>>>> - Admin: 3.3.0 > > >>>>>>>>>> Reason: ListConsumerGroupOffsetsOptions was deprecated in > 3.3.0 > > >>>>> and > > >>>>>>>>> was removed by > https://issues.apache.org/jira/browse/KAFKA-18291 > > >>>>>>>>>> > > >>>>>>>>>> You can find a list of all related JIRAs and pull requests in > this > > >>>>>>>>> Google Sheet: > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>> > https://docs.google.com/spreadsheets/d/1ZWNRk1rjWptjpGM2UtT0Q3lDULhrqkP_UfHr9roQW3M/edit?usp=sharing > > >>>>>>>>>> > > >>>>>>>>>> There are also some public methods removed in 4.0, such as: > > >>>>>>>>>> - KafkaFuture#Function, KafkaFuture#thenApply > > >>>>>>>>> https://issues.apache.org/jira/browse/KAFKA-17903 > > >>>>>>>>>> - JmxReported(String) > > >>>>>>>> https://issues.apache.org/jira/browse/KAFKA-18077 > > >>>>>>>>>> , but I'm uncertain about how we should handle these. > > >>>>>>>>>> > > >>>>>>>>>> Best, > > >>>>>>>>>> Kuan-Po > > >>>>>>>>>> > > >>>>>>>>>> On 2025/02/06 19:08:49 Chia-Ping Tsai wrote: > > >>>>>>>>>>> hi Kuan-Po > > >>>>>>>>>>> > > >>>>>>>>>>> any update? Now that an upgrade path for bridge versions > exists, we > > >>>>>>>>> can introduce additional "conditions" to assist users in > selecting the > > >>>>>>>>> "best" bridge version. For example, we can provide guidance on > which > > >>>>>>>> bridge > > >>>>>>>>> versions offer backward compatibility with Kafka 4.0 client or > are > > >>>>>>>>> compatible with Kafka 4.0 server. > > >>>>>>>>>>> > > >>>>>>>>>>> Best, > > >>>>>>>>>>> Chia-Ping > > >>>>>>>>>>> > > >>>>>>>>>>> On 2025/01/22 04:48:36 Chia-Ping Tsai wrote: > > >>>>>>>>>>>>> - 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. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Using a major version as a bridge is a viable approach. We > can > > >>>>>>>>> emphasize the limitations of this method to guide users in > selecting > > >>>>> the > > >>>>>>>>> most suitable bridge version. > > >>>>>>>>>>>> > > >>>>>>>>>>>>> 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. > > >>>>>>>>>>>> > > >>>>>>>>>>>> You make a valid point. The previous discussion overlooked > the APIs > > >>>>>>>>> that were removed in version 4.0. > > >>>>>>>>>>>> > > >>>>>>>>>>>> We could also emphasize the BC advantages. As an example, > users > > >>>>>>>> have > > >>>>>>>>> the option of using version 2.7 as a bridge and subsequently > upgrade > > >>>>>>>>> without code alterations or recompilation. Of course, we need > to check > > >>>>>>>> the > > >>>>>>>>> version of other PAPI removal. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Best, > > >>>>>>>>>>>> Chia-Ping > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>>> Matthias J. Sax <mj...@apache.org> 於 2025年1月22日 凌晨2:55 寫道： > > >>>>>>>>>>>>> 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. > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > >
