PDavid commented on code in PR #6262:
URL: https://github.com/apache/hbase/pull/6262#discussion_r1768168732
##########
hbase-protocol-shaded/src/main/protobuf/rest/VersionMessage.proto:
##########
@@ -24,4 +24,6 @@ message Version {
optional string osVersion = 3;
optional string serverVersion = 4;
optional string jerseyVersion = 5;
+ optional string version = 6;
Review Comment:
The short answer is: yes.
The long answer:
> ### Extending a Protocol Buffer
Sooner or later after you release the code that uses your protocol buffer,
you will undoubtedly want to “improve” the protocol buffer’s definition. If you
want your new buffers to be backwards-compatible, and your old buffers to be
forward-compatible – and you almost certainly do want this – then there are
some rules you need to follow. In the new version of the protocol buffer:
- you must not change the tag numbers of any existing fields.
- you must not add or delete any required fields.
- you may delete optional or repeated fields.
- you may add new optional or repeated fields but you must use fresh tag
numbers (that is, tag numbers that -
were never used in this protocol buffer, not even by deleted fields).
(There are [some
exceptions](https://protobuf.dev/programming-guides/proto2#updating) to these
rules, but they are rarely used.)
**If you follow these rules, old code will happily read new messages and
simply ignore any new fields.** To the old code, optional fields that were
deleted will simply have their default value, and deleted repeated fields will
be empty. **New code will also transparently read old messages.** However, keep
in mind that new optional fields will not be present in old messages, so you
will need to either check explicitly whether they’re set with has_, or provide
a reasonable default value in your .proto file with `[default = value]` after
the tag number. If the default value is not specified for an optional element,
a type-specific default value is used instead: for strings, the default value
is the empty string.
...
Source:
https://protobuf.dev/getting-started/javatutorial/#extending-a-protobuf
Besides I tested it like this:
- Took (copied) the Base64 encoded serialized protobuf message which also
contains the newly added version and revision fields:
```java
AS_PB =
"CgUwLjAuMRInU3VuIE1pY3Jvc3lzdGVtcyBJbmMuIDEuNi4wXzEzLTExLjMtYjAyGi1MaW51eCAyLjYuMTg"
+
"tMTI4LjEuNi5lbDUuY2VudG9zLnBsdXN4ZW4gYW1kNjQiBjYuMS4xNCoIMS4xLjAtZWEyFjQuMC4wLWFscGhhLT"
+
"EtU05BUFNIT1Q6KDUwODVkMjdhYjE3ZDg1NzExOGE5NmFlM2YzN2MwMGI2MGM5MjU0NzE=";
```
- Switched to the `master` branch (which does not yet have these version and
revision fields yet).
- In `TestVersionModel` I changed the serialized protobuf string to the new
one which has the new fields
- Run a Maven clean install to make sure the project is clean
- Executed `TestVersionModel` unit test which was green (was able to read
the protobuf message).
(I also tried out this in a small new Java project.)
--> older clients should read new message and newer clients should read old
messages without a problem.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
