lhotari commented on PR #20602: URL: https://github.com/apache/pulsar/pull/20602#issuecomment-1596760475
> This can be a relative big step on bumping versions. I agree, but that's not a reason to stop maintaining Pulsar. :) I think it's a very bad strategy to keep back from upgrading versions. If the project gets into a state where we are afraid to upgrade dependencies, that is the beginning of an end for the project itself. It's better to embrace failure and follow a "fail fast" approach and deal with the consequences. This applies at least to the `master` branch. With maintenance branches, we could choose a more conservative approach. For grpc upgrades, there is already some experience in doing this in the past. There have been issues in the past where grpc version has compatibility issues with protobuf version or netty version. That is why I'm upgrading protobuf at the same time. In this case, I don't expect there to be any netty version compatibility issue, but we will see. That's what CI is for, ensuring that things don't break after changes are made. > I remember that we don't use gRPC for pulsar broker and use lightproto for protobuf runtime. Do you have a brief on our usages and the impact of this upgrading? Yes, we use lightproto in Pulsar itself. gRPC is used in a few locations in Pulsar, for example within Pulsar Functions (status checks, BK state storage). We have test coverage to catch possible regressions. I have also created a similar PR to Bookkeeper (https://github.com/apache/bookkeeper/pull/3992) so that we could catch possible regressions in BK tests when grpc and protobuf versions are upgrade. -- 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]
