New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RELEASING.md: Bump protobuf version to match build.gradle #8551
RELEASING.md: Bump protobuf version to match build.gradle #8551
Conversation
For 1.40.0 the protobuf version was bumped to the latest version, which we hadn't tested at all. We want to bump to the version used in the release.
@@ -117,7 +117,8 @@ Tagging the Release | |||
$ git checkout v$MAJOR.$MINOR.x | |||
$ git pull upstream v$MAJOR.$MINOR.x | |||
$ git checkout -b release | |||
# Bump documented versions. Don't forget protobuf version | |||
# Bump documented gRPC versions. | |||
# Also update protoc version to match protocVersion in build.gradle. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, we are still using
Line 60 in 25022f6
protobufVersion = '3.17.2' |
And also need to update in examples?: https://github.com/grpc/grpc-java/search?q=protobufVersion
And s/protocVersion/protobufVersion? where is the protocVersion
come from? I can not understand it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two different versions of protoc we have in our repo at a time:
- The version we are actually using. This should be the same for the entire repo and applies to examples as well
- The version referenced in the README, which is the version the last release used
It is not appropriate to update the protobuf version being used as part of the release process. We want to continue using what we have been testing for a while. We do need to update any documentation though, and that's what is discussed here.
I said protocVersion because that's the variable that matters. Yes, the code happens to have protocVersion = protobufVersion
, but that isn't always the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea.
I did feel unclear when I was here doing the last release.
Just talking about document, we shouldn't use the new version, both the master and 1.40 should be using 3.17.2
in its documentation.
…c M1 Upgrade to the latest grpc-java 1.42.1 which is only compatible and [tested against](grpc/grpc-java#8551 (comment)) 3.17.2, but we can assume that 3.17.3 (which has osx-aarch_64 compatible maven artifacts) is save to use. We could have also upgrade to the latest grpc-java 1.42.1 and latest protoc 3.19.1, but it can not be directly done, it needs to tweak the grpcs-java internal dependencies. So we choose the safest option and discarded this option because of the following reasons: - Protoc 3.19.1 generates code that relies on methods not available in protobuf-java 3.17.2 ([“issue”](protocolbuffers/protobuf#9236 (comment))) (which java-grpc relies on). So we need to tell grpc-java via dependency management to use 3.19.1 instead of 3.17.2. Signed-off-by: Marc Navarro Sonnenfeld <marcnavarro@tetrate.io>
…c M1 Upgrade to the latest grpc-java 1.42.1 which is only compatible and [tested against](grpc/grpc-java#8551 (comment)) 3.17.2, but we can assume that 3.17.3 (which has osx-aarch_64 compatible maven artifacts) is save to use. We could have also upgrade to the latest grpc-java 1.42.1 and latest protoc 3.19.1, but it can not be directly done, it needs to tweak the grpcs-java internal dependencies. So we choose the safest option and discarded this option because of the following reasons: - Protoc 3.19.1 generates code that relies on methods not available in protobuf-java 3.17.2 ([“issue”](protocolbuffers/protobuf#9236 (comment))) (which java-grpc relies on). So we need to tell grpc-java via dependency management to use 3.19.1 instead of 3.17.2. Signed-off-by: Marc Navarro Sonnenfeld <marcnavarro@tetrate.io>
…c M1 Upgrade to the latest grpc-java 1.42.1 which is only compatible and [tested against](grpc/grpc-java#8551 (comment)) 3.17.2, but we can assume that 3.17.3 (which has osx-aarch_64 compatible maven artifacts) is save to use. We could have also upgrade to the latest grpc-java 1.42.1 and latest protoc 3.19.1, but it can not be directly done, it needs to tweak the grpcs-java internal dependencies. So we choose the safest option and discarded this option because of the following reasons: - Protoc 3.19.1 generates code that relies on methods not available in protobuf-java 3.17.2 ([“issue”](protocolbuffers/protobuf#9236 (comment))) (which java-grpc relies on). So we need to tell grpc-java via dependency management to use 3.19.1 instead of 3.17.2. Signed-off-by: Marc Navarro Sonnenfeld <marcnavarro@tetrate.io>
…c M1 (#8186) Upgrade to the latest grpc-java 1.42.1 which is only compatible and [tested against](grpc/grpc-java#8551 (comment)) 3.17.2, but we can assume that 3.17.3 (which has osx-aarch_64 compatible maven artifacts) is save to use. We could have also upgrade to the latest grpc-java 1.42.1 and latest protoc 3.19.1, but it can not be directly done, it needs to tweak the grpcs-java internal dependencies. So we choose the safest option and discarded this option because of the following reasons: - Protoc 3.19.1 generates code that relies on methods not available in protobuf-java 3.17.2 ([“issue”](protocolbuffers/protobuf#9236 (comment))) (which java-grpc relies on). So we need to tell grpc-java via dependency management to use 3.19.1 instead of 3.17.2. Signed-off-by: Marc Navarro Sonnenfeld <marcnavarro@tetrate.io>
For 1.40.0 the protobuf version was bumped to the latest version, which
we hadn't tested at all. We want to bump to the version used in the
release.