Sounds reasonable. We increment the serialization version every minor release
"just in case" anything has changed in the server-to-server protocol, but
client-to-server should change a lot less frequently, as you pointed out.
Now that Geode is maintaining support branches with longer life, rather that
our old model of releasing new minors linearly every 3 months and patch
releases hardly ever, there is increased likelihood of getting into a situation
where a newer patch on an older minor could increment the server-to-server
serialization version, and it would be great if this didn't unnecessarily break
clients.
On 2/23/21, 9:38 AM, "Bruce Schuchardt" <bru...@vmware.com> wrote:
I’m considering a change in client/server communications that I would like
feedback on.
We haven’t changed on-wire client/server communications since v1.8 yet we
tie these communications to the current version. The support/1.14 branch
identifies clients as needing v1.14 for serialization/deserialization, for
instance, even though nothing has changed in years.
If we put out a patch release, say v1.12.1, clients running that patch
version cannot communicate with servers running v1.12.0. They also can’t
communicate with a server running v1.13.0 because that server doesn’t know
anything about v1.12.1 and will reject the client. To solve that problem we
currently have to issue a new 1.13 release that knows about v1.12.1 and users
have to roll their servers to the new v1.13.1.
I propose to change this so that the client’s on-wire version is decoupled
from the “current version”. A client can be running v1.14.0 but could use
v1.8.0 as its protocol version for communications.
This would have an impact on contributors to the project. If you need to
change the client/server protocol version you will need to modify
KnownVersion.java to specify the change, and should let everyone know about the
change.
See
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8963&data=04%7C01%7Conichols%40vmware.com%7C450f013015004deac5e308d8d821cc7f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C637496986983812499%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=l4QPnp1D2nEK0G%2FI%2FhZ3UJ9PEDP2CDaJRWd3I6BISe0%3D&reserved=0
