...

1. Pull the abstract methods from the AbstractCoordinator class into a new interface, which will be part of Kafka's public API.
2. Change the visibility (from protected to public) of methods that have been added to this interface when needed.
3. Move these classes from the org.apache.clients.consumer.internals package to org.apache.clients.consumer
   1. org.apache.kafka.clients.consumer.internals.AbstractCoordinator → org.apache.kafka.clients.consumer.AbstractCoordinator
   2. org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient → org.apache.kafka.clients.consumer.ConsumerNetworkClient
   3. org.apache.kafka.clients.consumer.internals.Heartbeat → org.apache.kafka.clients.consumer.Heartbeat
   4. org.apache.kafka.clients.consumer.internals.RequestFuture → org.apache.kafka.clients.consumer.RequestFuture
   5. org.apache.kafka.clients.consumer.internals.RequestFutureAdapter → org.apache.kafka.clients.consumer.RequestFutureAdapter
   6. org.apache.kafka.clients.consumer.internals.RequestFutureListener → org.apache.kafka.clients.consumer.RequestFutureListener
4. Adjust the method visibility for the moved classes when required.
5. This KIP does not include any changes to the Admin APIs. Potential changes to the Admin/KafkaAdminClient classes (such as adding methods to query for group metadata from brokers) will be addressed in a separate KIP.

For a list of the propose changes, please refer to the the pull-request: KIP-795 Make AbstractCoordinator part of the public API #11515

Compatibility, Deprecation, and Migration Plan

...