On Mon, Aug 26, 2019 at 9:28 PM Duo Zhang <[email protected]> wrote:
> I think this is a problem for the 3.0.0 release. When upgrading to 2.0.0, > we shaded the protobuf and upgrade the version to 3.x. But for coprocessor, > the protobuf version is still 2.5.0, and we made a hbase-protocol module > for it. > Yes. This was intentional. Didn't want to break existing endpoint coprocessors going from branch-1 to branch-2 as part of the shade protobufs project (HBASE-15638). So we still keep this solution when releasing 3.0.0? Which means the > protobuf version for coprocessor will always be 2.5.0? Seems not a good > solution. > And since we are allowed to make breaking changes on the CP hooks during > major version, I think letting the CPs use a new version of protobuf is > also fine? > > Suggestions? > > The doc attached to HBASE-15638 had some thoughts on this ( https://docs.google.com/document/d/1H4NgLXQ9Y9KejwobddCqaVMEDCGbyDcXtdF5iAfDIEk/edit#heading=h.yh3l2y26xbvk) and HBASE-16761 <https://issues.apache.org/jira/browse/HBASE-16761> was filed for moving CPEPs to pb3. + PB Service is the mechanism CPEPs are built on. Our classpath will carry PB2.5 until Hadoop moves off it so we won't be able to expose com.google.protobuf.* in our API if its not pb2.5. Expose a shaded c.g.protobuf? But at a different shade point than that of the pb we use internally so we can continue to freely upgrade the pb we use internally w/o breaking CPEPs? Or try to hide the implementation? And so on.... Thanks for bringing this up. S > Thanks. >
