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