gNMI Versioning and Backwards Compatibility

[abhinava]

Is there any guidance on client compatibility when it comes to gNMI?

For example, the latest version is "0.7.0". Should a gRPC/gNMI server that implements 0.7.0 be able to interop with a client that only understands 0.5.0? From the OpenConfig semantic versioning scheme (ref), it seems that as long as the major version remains the same, the client <---> server need to interop. Could you please confirm if this applies to gNMI as well?

Is this true even though the gNMI proto definition itself has gone through some changes over the years (which I think could've been a reason to bump up the major version - For example, use of the Update message with TypedValue fields instead of the older scheme, use of a list of PathElem rather than string to indicate XPaths, ...)

BTW, Section 3.2.2 (ref) that points to the OpenConfig semantic versioning page has a dead link. It should be: http://openconfig.net/docs/semver/

[aashaikh]

For version 0.x.x data models, the intention is to allow backward incompatible changes without incrementing the major version number until the model is moved to 1.x.x -- this is in recognition of the early stages of development/adoption/maturity and relatively rapid changes. I think we've implicitly adopted the same for RPC definitions.

We can discuss in the working group whether we should move gNMI to a 1.x version.

[abhinava]

Thanks for your quick response @aashaikh !

[aashaikh]

I forgot to also mention that protobufs have their own conventions for maintaining backward compatibility and we do generally adhere try to those rules.