Closed mdub closed 1 month ago
This kind of binary incompatibility has happened before (refer https://github.com/confluentinc/schema-registry/issues/2715), and seems likely to happen again, given the use of "com.squareup.wire.schema.internal.parser" classes by the Confluent code.
I wonder if there is a way for Confluent to achieve the same thing, using only stable, public APIs. Do you have any suggestions, @oldergod?
We're doing our best in Wire not to break public APIs, and that still might happens from time to time. Data classes are very difficult to change without breaking backward compatibility (this is why Wire doesn't generate data classes btw). If Schema Registry is having trouble because of its usage of an internal Wire API, then I would recommend migrating out of it.
Support for wire-schema 5.0.0 will available in 7.8.0
I'm using
io.confluent:kafka-protobuf-provider:7.7.1
After upgrading to
com.squareup.wire:wire-schema:5.0.0
(or later), parsing a ProtobufSchema, e.g.fails with an exception:
I have a full working (well, failing) example in https://github.com/mdub/confluent-schema-registry-wire-upgrade/tree/sr-7.7.1-vs-wire-5.0.0.
It appears it was triggered by https://github.com/square/wire/pull/2966, which changed internal classes in a binary-incompatible way.