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