In hbase 3.0.0 we removed the hbase-protocol module, and also let CPs
make use of the shaded version too, as we already saw some users
report that they want to use something like grpc in CP but CP needs to
depend on protobuf 2.5 which introduces conflicts.
So I think in 3.0.0, I agree with you that we need to also add
InterfaceAudience for protobufs, to clearly tell users what things you
can use and what you can not. But in general, I do not think any
protobufs should be IA.Public, IA.LimitedPrivate("CP") is enough.
Thanks.
Bryan Beaudreault <[email protected]> 于2021年8月12日周四 上午2:16写道：
>
> 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.
> > >
> >
