I Wrote this last Friday, but forgot to send it out. Similar to what Yun said.
It's true that users can mix different client and server versions in their environments. However, version interoperability should be a core design goal for Polaris or any web service. Specifically: - *Server Backward compatibility is a must-have*: newer server versions must continue to support older clients. We cannot expect each server update to break existing clients. There are exceptions like removal of endpoints, which should be planned and announced and go through the deprecating process. - *Server Forward compatibility is desirable*: newer clients should be able to interact with older servers, though they may not get access to newer features. So for example, a v1.2 client can seamlessly connect to any server with version v1.2 or above. If it connects to an older server (v1.0 or v1.1), it will still function but some newer features of v1.2 may not be available. The Iceberg field "endpoints" in /v1/config is especially designed for that. It isn't perfect, but covers most of the use cases. With that, it's much easier for users to understand how compatibility applies, if we release them with the same version number. Yufei On Fri, Apr 4, 2025 at 5:36 PM Dmitri Bourlatchkov <di...@apache.org> wrote: > Hi Yun, > > Your proposal LGTM. > > However, regarding compatibility, I think this information has to be > tracked regardless of the release cycle, because users can mix different > client / server versions in their environments. > > Cheers, > Dmitri. > > On Tue, Mar 25, 2025 at 5:01 PM yun zou <yunzou.colost...@gmail.com> > wrote: > > > Hi Team, > > > > Given that we are now introducing Spark Client, one thing we need to > decide > > is the release cycle for the Spark Plugin. > > > > I propose to bundle the client release with Polaris main release like > > Iceberg. In that way, users will be able to get the client support for > new > > APIs in the same release, and version compatibility is also implicitly > > implied in the release. > > > > An alternative is to release the client independently like > > spark-cassandra-connector. In that case, the client will not have to do > > extra release if there is no server API change. The drawback is that the > > client release will need to start after the server release is finished in > > case there are new changes, and extra Compatible Version information > needs > > to be published to help users understand the compatibility. > > > > Please let me know about your thoughts on the client release cycles. > > > > Best Regards, > > Yun > > >
