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).
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? "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 >
