Bump grpc and protobuf versions

[jack-berg]

No description provided.

[jack-berg]

@trask and @laurit - not sure how we should approach a release with this update. As noted in the linked issues, this is blocking the adopt of com.google.protobuf:protobuf-bom:v4 in the core and instrumentation repos.

Options:

1. Wait for a release of opentelemetry-proto. Not clear when that might be. The only activity going currently going on is related to profiles, but not sure when they would want to cut a release.
2. Cut a release with some extra suffix, i.e. 1.32.2-1-alpha or 1.32.2-20240923-alpha. Note, the release automation doesn't have any tooling for this so would need to execute the release locally from my machine, or enhance the release automation. Given the infrequency of releases of this repo, I'd prefer to make a one-off release locally from my machine, since I changing release automation is brittle and wouldn't be exercised often.

[trask]

what do you think of breaking the version sync between this and the proto repo (maybe releasing 2.0.0 from this repo)?

or asking opentelemetry-proto to only release minor versions going forward, so that implementations can use patch versions for themselves? I don't think there's any rush on getting this particular change out if we can decide on a long-term strategy

[jack-berg]

semantic-conventions-java has the same problem of being coupled to the versioning scheme of another repo. I think in semantic-conventions-java we decided to use a 4th semconv element (basing off this note in releasing, which we haven't actually needed in practice yet).

Ideally we employ the same pattern in both places. And it does seem useful to pin semantic-conventions-java to the corresponding version of semantic-conventions.

or asking opentelemetry-proto to only release minor versions going forward, so that implementations can use patch versions for themselves?

Going through the opentelemetry-proto release history, we've only seen patch be used for 1.3.1 and 1.3.2. So maybe this is feasible, but also seems restrictive. Cutting a patch for opentelemetry-proto sends a signal that something was borked and you really need to use the patch. In contrast, if a new minor version is released to solve problems, consumers might mistakenly take a more permanent dependency on it, which isn't good.

[trask]

semantic-conventions-java has the same problem of being coupled to the versioning scheme of another repo. I think in semantic-conventions-java we decided to use a 4th semconv element (basing off this note in releasing, which we haven't actually needed in practice yet).

I support that. It's not technically semver, but that is probably mainly a technicality given maven/gradle/dependabot/renovate should all support a 4th digit (in terms of version ordering/precedence).

[patpatpat123]

Hello team, thank you very much for this merge. May I ask when will this be released?