Hi Yun, > For compatibility, if the client releases along with the server, one implicit guarantee we will make [...]
I do not think implicit compatibility guarantees work very well in practice. Of course, users assume that the client and the server of the server version are compatible. However, that will tie the client version to the server version, which may or may not be ideal in the future. That said, there will always be cases when client and server versions do not match, and in that case compatibility cannot really be implicit as issues may not be discovered in time, and released artifacts (identified by the version) cannot be fixed after discovering compatibility issues. Cheers, Dmitri. On Thu, Apr 10, 2025 at 6:03 PM yun zou <yunzou.colost...@gmail.com> wrote: > Hi Dmitri, > > Thanks a lot for the feedback! > > For compatibility, if the client releases along with the server, one > implicit guarantee we > will make is that one version of the client will be compatible with the > server of the same > version and the versions after until there is some API field deprecation. > For example, > a client released in 1.0.0 will be compatible with server >= 1.0.0. If in > server version 1.2.3, > a field in one particular API is deprecated, then client 1.0.0 will not be > compatible with > server version >= 1.2.3. We will definitely need to make sure such > information is published in the > Polaris webpage and Client README, or another place we think should contain > the information. > > Furthermore, I think it is important for the server to maintain the API > backward > compatibility, for example: only add extra optional fields for existing > APIs, and give enough time > before completely deprecating a field of an existing API etc. > > Please let me know if that makes sense. Thanks again for the feedback! > > Best Regards, > > > > 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 > > > > > >
