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