Hi Harsha, Comments inline.
On Fri, Apr 12, 2019 at 8:22 PM Harsha <ka...@harsha.io> wrote: > Hi Ismael, > I meant to say blocking clients based on their API version > https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/api/ApiVersion.scala#L48 > But If I understand what you are saying, since each client release can > support different versions for each of fetch, produce, offset commit etc.. > and it's harder to block just based on single min.api.version setting > across different clients. > That's what I mean, yes. > The idea I had in my mind was to do this via ApiVersionRequest, when a > client makes api request to broker in response we return min and max > version supported for each Api. When min.api.version enabled on broker, it > returns the maxVersion it supports for each of the requests in that release > as min versions to the clients. > Yes, my concern is not the implementation, that's straightforward, it's how it's meant to be used. Irrespective of the above approach I understand your point still stands > which is sarama might not choose to implement all the higher version > protocols for Kafka 1.1 release and they might introduce higher version of > produce request in a subsequent minor release and it will be harder for > users to figure out which release of sarama client they can use. > Yes, that's exactly right. The current KIP is not treating the Kafka protocol as a specification that is implemented by multiple clients in multiple languages. During KIP-35, it was agreed that the protocol would not be tied to a particular Kafka version. The current KIP proposal doesn't take that into account. I looked at the latest updates and I don't think the core issue is addressed: https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=103091409&selectedPageVersions=15&selectedPageVersions=13 It would be useful to hear feedback from other people. Ismael
