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
