We have proposed and discussed majorly three approaches so far, there were many minor versions with small variations. Comparing them really requires a side by side proposal and their pros/cons, and I agree with others that this has been lacking in the KIP. We just updated the KIP with following details.
1. Provide proposed changes in all the three proposals we have discussed so far. Except the current proposal, these proposals are in rejected alternatives. 2. Provide reasoning on why the rejected proposals were rejected. 3. Add scenarios for all of these proposals from a client developer and core Kafka developer point of view. As we are really close to 0.10 deadline, a quick round of voting will really help. If you really do not like the idea, please feel free to say so. If the vote fails for the current proposal, it can at lease provide recommendations that we should consider for next version of proposal and put it up for vote again for next release. However, as stated earlier by multiple people having this ASAP will be awesome. On Thu, Mar 17, 2016 at 3:29 PM, Dana Powers <dana.pow...@gmail.com> wrote: > On Thu, Mar 17, 2016 at 1:42 PM, Gwen Shapira <g...@confluent.io> wrote: > > > "I think I would make this approach work by looking at the released > server > > version documentation for each version that I am trying to support and > test > > against*, manually identify the expected "protocol vectors" each > supports, > > store that as a map of vectors to "broker versions", check each vector at > > runtime until I find a match, and write code compatibility checks from > > there." > > > > How is this better than a global version ID? > > > As a client developer, it seems roughly the same. I think it probably > avoids the server development workflow issues, and possibly the need to > agree on semantics of the global version ID? But others surely are more > qualified than me to comment on that part. > > -Dana > -- Regards, Ashish
