Major update to protobuf 4.x causing conflicts with popular packages. #421
Comments
…llographql#386)" This reverts commit bf80d91. AND Prevents protobuf from being automatically upgraded to a major version without proper compatibility studies with other popular packages. Details at apollographql#421
|
Hi there! I wanted to just comment in here and see how things were looking to either get the revert out or to upgrade to a slightly higher version of protobuf - 4.28.2 seems to be working alright now. It primarily stemmed from grpc/grpc-java#11015 where they mentioned that 4.28+ is backwards compatible for others. Could we at least go up to that? |
|
I was also wondering if there is any update on this issue. We use Netflix DGS (which uses federation-jvm) in our applications along with the kafka protobuf serializer and schema registry (from Confluent) which is still using protobuf java 3.x and it is documented as not compatible with 4.x. Based on our testing, the confluent stuff is not compatible even with the later versions of 4.x that introduce some backwards compatibility. This has created dependency conflicts for us with the protobuf java versions, and we're currently considering setting a dependency constraint in our projects to downgrade back to protobuf java 3.x so that we can use Netflix DGS 9.x or 10.x, both of which bring in protobuf java 4.x because of the more recent federation-jvm releases. We don't love this solution, but otherwise we don't have a path forward to adopt more recent releases of Netflix DGS and Spring Boot. Please do consider downgrading back to protobuf java 3.x for what appears to be greater compatibility with other major open source dependencies, especially if federation-jvm is not using any new feature in 4.x. Thanks! |
We are using protobuf to generate `ftv1` tracing information. Protobuf v4 made a backwards incompatible change that prevents using those messages with v3 services. Since there are a lot of existing libraries (including `grpc-java`) that still depend on the v3 format and generated protobuf v3 message can be used for both v3 and v4 services we'll be reverting to v3 as well. See: grpc/grpc-java#11015 (comment) Resolves: #421
|
Thanks for raising this issue. It appears that even using newer versions of protobuf doesn't work with services using v3 versions. Since we only use it to generate the messages and the generated v3 message is compatible with v3 and v4, we are going to downgrade to v3. |
|
@dariuszkuc thanks for considering this and responding so quickly, really appreciate it! Once a new release of federation-jvm is done, at least in my case we'd need to wait for Netflix DGS to also adopt it. I noticed they have added a strict constraint in their BOM for protobuf-java in multiple places. Do you actively work with the Netflix DGS team to make sure they adopt your new releases? |
|
Thank you so much |
`federation-jvm` v5 included a bump to a protobuf v4 version which is not ABI compatible with protobuf v3. A lot of the libraries in the `grpc` ecosystem are still stuck at v3 (including `grpc-java`) and since `federation-jvm` only uses protobuf to generate messages, the latest `federation-jvm` version also downgrades its dependency back to a v3 version (which generates messages that are compatible with both v3 and v4 versions of protobuf). related: * apollographql/federation-jvm#421 * grpc/grpc-java#11015
Pull/386 made a major update to protobuf version 4.x and some groups are reporting conflicts due to this update with other popular packages such as all Java clients from the Google API ecosystem (Google Cloud, all services, etc.). I understand that this major protobuf update (3.x ->4x) was created automatically by renovatebot and there is no immediate use of protobuf 4.x features. Version 3.25.x is used by the vast majority of projects, incredibly popular..
Any chance of reverting this major update and hoping that other popular projects can be updated to 4.xx?
The text was updated successfully, but these errors were encountered: