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