Hello all, Quick update, I just updated the KIP with a note about the console consumer, where we are ensuring the recommendation log shows even if INFO level is not enabled (the console tool already prints notifications to the standard output, so just doing the same)
Lianet On Sun, Feb 15, 2026 at 10:41 PM Lianet Magrans <[email protected]> wrote: > Hi David, > > I updated the KIP, explicitly mentioning the classic methods that will > follow the same deprecation/removal cycle, along with the configs. > > Thanks! > Lianet > > On Sat, Feb 14, 2026 at 3:28 PM David Jacot <[email protected]> wrote: > >> Hi Lianet, >> >> Continuing on Matthias’ point, we also need to deprecate a few methods and >> the client-side assignor interface. For reference, they are all mentioned >> in KIP-848. I would suggest to clearly mention them (including configs) in >> the public interface section. >> >> Best, >> David >> >> Le sam. 14 févr. 2026 à 14:32, Lianet Magrans <[email protected]> a >> écrit : >> >> > Hi Matthias, >> > >> > - I clarified in the KIP around the group.protocol config. The >> intention is >> > indeed to deprecate the public-facing group.protocol config in 5.0 and >> > remove in 6.0. The references to the property in the 6.0 phase is just >> > considering that users could still provide it as a string (in which case >> > group.protocol=consumer would just log an used prop, >> group.protocol=classic >> > would fail with a ConfigException for an unsupported protocol). >> > - Good callout about the other classic properties, they are treated >> > consistently with the group.protocol. I updated the KIP to clarify >> > (deprecate them in 5, remove them in 6, keep them for internal usage by >> KS >> > if needed) >> > >> > Please take a look and let me know. Thanks! >> > Lianet >> > >> > >> > >> > On Fri, Feb 13, 2026 at 3:08 PM Matthias J. Sax <[email protected]> >> wrote: >> > >> > > Thanks Lianet. Curious to hear what others think. >> > > >> > > I had a few follow up questions: >> > > >> > > - The KIP is not totally clear, if we would only remove "classic" >> as a >> > > valid parameter for `group.protocol`, of if `group.protocol` would be >> > > deprecated and removed by itself entirely. -- If `group.protocol` has >> > > only one allowed value "consumer" with AK 6.0 it would be somewhat >> odd? >> > > So removing the config entirely might be best? >> > > >> > > - What about the client-side config (like "session.timeout.ms" and >> > > others) which are only used for "classic" (and are broker configs with >> > > "consumer"). As they become useless with AK 6.0 release, should we >> also >> > > deprecate all of them with AK 5.0 and remove with AK 6.0 along with >> > > `group.protocol`? >> > > >> > > >> > > >> > > -Matthias >> > > >> > > >> > > On 2/13/26 7:12 AM, Lianet Magrans wrote: >> > > > Hi Matthias, thanks for the feedback! >> > > > >> > > > - About phase 1: I think the main goal at this point is to >> > > > clearly communicate the recommendation in applications not using the >> > new >> > > > protocol. We can achieve that via an info message (and introduce the >> > warn >> > > > when we deprecate, as in the KIP), so agreed. Updated phase 1 with >> > this. >> > > > - About phase 3 and how to handle the unused configuration, I agree >> > with >> > > > letting it be if set to consumer, just warning about an unused >> > property, >> > > > but I would say we should still fail if set to classic (as this >> will be >> > > an >> > > > unsupported protocol by then). Makes sense? I updated the KIP >> > > accordingly, >> > > > take a look and let me know your thoughts. >> > > > >> > > > Thanks! >> > > > Lianet >> > > > >> > > > On Wed, Feb 11, 2026 at 2:52 AM Matthias J. Sax <[email protected]> >> > > wrote: >> > > > >> > > >> Thanks for the update Lianet. >> > > >> >> > > >> About Phase 1: while I understand the sentiment to push users to >> > migrate >> > > >> off "classic", I am wondering if logging a WARN level log would be >> the >> > > >> right thing, or if INFO level would be better/sufficient? It seems >> odd >> > > >> that we log a WARN for the default config (ie, I use a vanilla >> > > >> configuration and get an WARN). >> > > >> >> > > >> It is for sure appropriate to log a WARN starting in Phase 2, when >> > > >> "classic" is officially deprecated, as already stated on the KIP. >> > > >> >> > > >> If the overall sentiment is "yes, we really want a WARN log with >> 4.3" >> > > >> (as we really want to push on this, and users can get rid of the >> WARN >> > by >> > > >> switching to "consumer"), also ok with me. -- For this case, might >> be >> > > >> good to add a short bullet point to "Rejected Alternatives" >> section? >> > > >> >> > > >> >> > > >> >> > > >> I also have concerns personally for Phase 3, about throwing a >> > > >> `ConfigException` when `group.protocol` is still used -- it seems >> > better >> > > >> to me, to no throw, but just treat it s as any other "foo.bar" >> config >> > > >> the consumer does not understand, and just log a WARN about >> "unknown >> > > >> config". -- This one bother me somewhat more compare to my "phase 1 >> > > >> question". >> > > >> >> > > >> >> > > >> >> > > >> For Kafka Streams, the KIP make sense to me. With 4.2 we are >> > production >> > > >> ready (GA) but not yet feature complete compared to "classic" and >> thus >> > > >> we cannot provide a timeline for moving off "classic" yet. We still >> > have >> > > >> the goal to become feature complete with 4.x release series, and to >> > > >> follow this KIP to deprecate "classic" for Kafka Streams with 5.x >> > > >> release, and remove with 6.x. But we can only do this with a >> separate >> > > >> KIP after we are feature complete with 1071. >> > > >> >> > > >> >> > > >> The parts about Connect also make sense to me. >> > > >> >> > > >> >> > > >> >> > > >> -Matthias >> > > >> >> > > >> >> > > >> >> > > >> On 2/9/26 8:03 AM, Lianet Magrans wrote: >> > > >>> Hi David, >> > > >>> >> > > >>> Good callout about Kafka Streams. >> > > >>> >> > > >>> - Agreed that we depend on 1071 timeline for phase 3 (remove >> classic >> > > >>> support in consumer in AK 6.0). Added a note on the KIP phase 3 >> > > >>> - If classic is still needed for streams by then, I think we >> should >> > > >> ideally >> > > >>> aim for keeping support internally only, while streams completes >> the >> > > >>> transition. I added a section to the KIP with the details so we >> can >> > all >> > > >>> align >> > > >>> >> > > >> >> > > >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1274%3A+Deprecate+and+remove+support+for+Classic+rebalance+protocol+in+KafkaConsumer#KIP1274:DeprecateandremovesupportforClassicrebalanceprotocolinKafkaConsumer-KafkaStreams >> > > >>> >> > > >>> >> > > >>> Thoughts? Thanks! >> > > >>> >> > > >>> Lianet >> > > >>> >> > > >>> >> > > >>> >> > > >>> On Fri, Feb 6, 2026 at 2:54 AM David Jacot via dev < >> > > [email protected] >> > > >>> >> > > >>> wrote: >> > > >>> >> > > >>>> Hi Lianet, >> > > >>>> >> > > >>>> The proposed approach looks good to me. I think that we should >> also >> > > >>>> consider Kafka Streams because it relies on the classic consumer >> and >> > > the >> > > >>>> timeline for KIP-1071 becoming the only option is not defined >> yet. >> > It >> > > >> seems >> > > >>>> that we have two options: 1/ Keep the classic consumer until >> Kafka >> > > >> Streams >> > > >>>> no longer needs it; or 2/ Keep it internally so Kafka Streams can >> > > >> continue >> > > >>>> to use it. Thoughts? >> > > >>>> >> > > >>>> Best, >> > > >>>> David >> > > >>>> >> > > >>>> On Wed, Jan 28, 2026 at 9:54 PM Lianet Magrans < >> [email protected]> >> > > >> wrote: >> > > >>>> >> > > >>>>> Hi all, so aligning with the latest points: >> > > >>>>> >> > > >>>>> - I updated the timeline mainly to better place the deprecation >> > step >> > > as >> > > >>>>> suggested, starting with the option of deprecating along with >> the >> > > >> default >> > > >>>>> change. Along the lines of : warn default/deprecation -> change >> > > >> default + >> > > >>>>> deprecate -> remove >> > > >>>>> - Also updated the content around the group.protocol property, >> > going >> > > >> back >> > > >>>>> to the initial proposal of removing it as unneeded after the >> > > >> transition. >> > > >>>>> >> > > >>>>> Thoughts? >> > > >>>>> >> > > >>>>> Thanks! >> > > >>>>> Lianet >> > > >>>>> >> > > >>>>> On Wed, Jan 28, 2026 at 2:13 PM Ismael Juma <[email protected]> >> > > wrote: >> > > >>>>> >> > > >>>>>> Hi Matthias, >> > > >>>>>> >> > > >>>>>> See inline. >> > > >>>>>> >> > > >>>>>> On Tue, Jan 27, 2026 at 7:43 PM Matthias J. Sax < >> [email protected] >> > > >> > > >>>>> wrote: >> > > >>>>>> >> > > >>>>>>> Also, if we want to make "consumer" default with AK 5.0, it >> seems >> > > >>>>>>> reasonable to start the deprecation cycle now. In general, we >> aim >> > > to >> > > >>>>>>> have a one year deprecation period, so if we deprecate only in >> > one >> > > >>>>> year, >> > > >>>>>>> eg 4.6, we could only change the default if there is also 4.7 >> and >> > > 4.8 >> > > >>>>>>> release before 5.0 (or violate the one year guarantee we >> usually >> > > >>>>>>> provide). This sounds unnecessary risky. >> > > >>>>>>> >> > > >>>>>> >> > > >>>>>> This is not accurate - it's totally ok to change a default >> config >> > > >>>> without >> > > >>>>>> deprecating one of the config values. >> > > >>>>>> >> > > >>>>>> Ismael >> > > >>>>>> >> > > >>>>> >> > > >>>> >> > > >>> >> > > >> >> > > >> >> > > > >> > > >> > > >> > >> >
