Thank you Stack, I did not see that issue or those references. So it seems like an issue already exists for this and in fact this discussion has already been solved :)
I'll move forward with my rename. I might comment on the issue, as I think adding a link in the "Aspirational Semantic Versioning" section might have avoided this confusion. On Wed, Aug 11, 2021 at 1:41 PM Stack <[email protected]> wrote: > On Tue, Aug 10, 2021 at 10:48 AM Bryan Beaudreault > <[email protected]> wrote: > > > Hello dev list, > > > > This question came up in https://github.com/apache/hbase/pull/3536 > <https://github.com/apache/hbase/pull/3536>, > where > > I > > renamed a field on the BalanceRequest message in Master.proto. > > > > This change is backwards compatible to the majority of users, because > > protobuf does not actually care about the name of the field (only the > > ordinal/id). So long as someone is interacting with MasterRpcServices > > through the Admin/AsyncAdmin interfaces, they would be completely unaware > > of the renamed field under the covers. > > > > One concern I had was for people with their own forks, or 3rd party > clients > > as Nick brought up. In those cases, they would get a compile time error > > when building. > > > > We don't explicitly cover protobufs in our > > http://hbase.apache.org/book.html#hbase.versioning.post10 > <http://hbase.apache.org/book.html#hbase.versioning.post10> > documentation. > > Nick suggested that it might make sense to consider the protobufs part of > > the LimitedPrivate API but would like to open that up to other opinions. > > > > > We have the modules hbase-protocol and hbase-protocol-shaded. They host our > 'protocol' spec'd in protobuf proto files and the classes generated from > proto files by protoc. The latter, shaded version, was made so we could > freely update the protobuf version we used internally and change protobufs > w/o having to worry about downstreamers or running into conflict w/ > upstream (hadoop). Effectively, it was treated as though it > interfaceaudience private. We should probably stamp it so (and I think this > means your change can be made w/o concern for downstreamers). > > hbase-protobuf was for use in those locations where we had protobuf as part > of our public API; in particular, our use of protobuf describing interfaces > for coprocessor endpoints. This latter module uses the EOL'd protobuf > version 2.5.0. It was sort-of public but also was being let atrophy as > often protobuf changes were made in the shaded module and not made here, > particularly if for internal-use only. hbase-protocol needs some work > (Related https://issues.apache.org/jira/browse/HBASE-16756 > <https://issues.apache.org/jira/browse/HBASE-16756> > ). > > S > > > > > > If we reach a consensus I would be happy to submit a jira to update our > > docs. > > >
