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 > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > > >
