alamb opened a new issue, #40424: URL: https://github.com/apache/arrow/issues/40424
### Describe the enhancement requested I would like to discuss adding "versions" or "compatibility levels" to FlightSQL ## Usecase The usecase is now that FlightSQL is being adopted across products, there is an increasing number of installed clients. As we make changes / add optional features to the spec such as: * https://github.com/apache/arrow/issues/37720 The question arises "how will clients/servers know what to expect" -- At the moment, the spec defines certain features that are "optional" such as XXX (and a new optional behavior such as https://github.com/apache/arrow/pull/40243). This means: 1. Updates to the spec must carefully define what should happen when the client and/or server do not use the optional feature 2. Clients and Servers must similarly handle a variety of potentially present and missing features An example of this subtlety is shown in the context of https://github.com/apache/arrow/issues/37720 where we are discussing "how should the server tell if the client is using the updated semantics" on https://github.com/apache/arrow/pull/40243 with @erratic-pattern @lidavidm and @pitrou https://github.com/apache/arrow/pull/40243#pullrequestreview-1912699524 ## Possible solutions One possible ### Component(s) FlightRPC -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
