Breaking API change
hhanh00 opened this issue · comments
What is the bug?
TreeState used to have a tree field in V4.
In V5, it has saplingTree and orchardTree but tree.
I appreciate the new API providing both sapling and orchard commitment tree states.
The issue is that with a lack of backward compatibility and versioning, old clients will fail when they connect to a newer server.
I suggest you do not change the existing API and introduce new methods for Orchard.
Thanks,
--h
This is not a breaking change. gRPC uses protobuf, which is designed to precisely enable these kinds of changes, because fields are not referenced by name, but by index. Specifically, the saplingTree field uses the same field index as the previous tree field, so the two names are equivalent. Old clients using an earlier version of the protobuf file to speak with a newer lightwalletd will ignore the newer orchardTree field and still get the Sapling tree.
If what you are referring to is the fact that us renaming the field in the protobuf definition in this repository causes locally generated APIs to be renamed (which wouldn't affect old clients), then the solution is to either rename that field back to tree in your local copy of the protobuf file, or update the client code to use the new field names at the same time as the client is updated with the new protobuf definition.
Sounds good. Thanks!