On Fri, Apr 1, 2016 at 1:32 AM, Ismael Juma <ism...@juma.me.uk> wrote:
> Two more things: > > 3. We talk about backporting of new request versions to stable branches in > the KIP. In practice, we can't do that until the Java client is changed so > that it doesn't blindly use the latest protocol version. Otherwise, if new > request versions were added to 0.9.0.2, the client would break when talking > to a 0.9.0.1 broker (given Jason's proposal, it would fail a bit more > gracefully, but that's still not good enough for a stable branch). It may > be worth making this clear in the KIP (yes, it is a bit orthogonal and > doesn't prevent the KIP from being adopted, but good to avoid confusion). > Good point. Adding this note and also adding a note that Kafka has not backported an api version so far. > > 4. The paragraph below is a bit confusing. It starts talking about 0.9.0 > and trunk and then switches to 0.9.1. Is that intentional? > Yes. > > "Deprecation of a protocol version will be done by marking a protocol > version as deprecated in protocol documentation. Documentation shall also > be used to indicate a protocol version that must not be used, or for any > such information.For instance, say 0.9.0 had protocol versions [0] for api > key 1. On trunk, version 1 of the api key was added. Users running off > trunk started using version 1 of the api and found out a major bug. To > rectify that version 2 of the api is added to trunk. For some reason, it is > now deemed important to have version 2 of the api in 0.9.1 as well. To do > so, version 1 and version 2 both of the api will be backported to the 0.9.1 > branch. 0.9.1 broker will return 0 as min supported version for the api and > 2 for the max supported version for the api. However, the version 1 should > be clearly marked as deprecated on its documentation. It will be client's > responsibility to make sure they are not using any such deprecated version > to the best knowledge of the client at the time of development (or > alternatively by configuration)." > > Ismael > > > > On Fri, Apr 1, 2016 at 9:22 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > A couple of questions: > > > > 1. The KIP says "Specific version may be deprecated through protocol > > documentation but must still be supported (although it is fair to return > an > > error code if the specific API supports it).". It may be worth expanding > > this a little more. For example, what does it mean to support the API? I > > guess this means that the broker must not disconnect the client and the > > broker must return a valid protocol response. Given that it says that it > is > > "fair" (I would probably replace "fair" with "valid") to return an error > > code if the specific API supports it, it sounds like we are saying that > we > > don't have to maintain the semantic behaviour (i.e. we could _always_ > > return an error for a deprecated API?). Is this true? > > > > 2. ApiVersionQueryRequest seems a bit verbose, why not ApiVersionRequest? > > > > Ismael > > > -- Regards, Ashish
