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