Skip to content
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

Breaking changes identification #20

Open
DavidNavalho opened this issue Dec 9, 2021 · 0 comments
Open

Breaking changes identification #20

DavidNavalho opened this issue Dec 9, 2021 · 0 comments

Comments

@DavidNavalho
Copy link

Couple of notes regarding schema registries:
1.
I'd like to propose that the authors of this spec re-consider how to detect breaking changes. Confluent's model of global backward/forward compatibility modes worked in the past, especially with things like Avro, but it's an essentially broken model nowadays, especially once you add Protobuf3 into the mix, which is much richer in it's specification.

I recommend having a look at this project: buf.build, specifically how they manage breaking changes in their CLI: https://docs.buf.build/breaking/rules

The main thing here is the configurability. They have multiple breaking change levels, but we can also provide a configuration file with more fine grained solutions. In a world of governance, multi language ecosystems, potentially mono vs multi repos, etc, it makes a lot more sense to have further control on what is the definition of a breaking schema.

Again, I recommend a divergence on how schemas are validated vs the implementation of Confluent's Schema Registry. Consider as well what a schema is, technically - a data model - and instead of checking if a schema is breaking against another, also validate if it is EQUIVALENT. This is an important distinction if we intend to support multi-languages and/or compilers.

Again, while this is much more prevalent in Protobuf, there are some issues with avro as well, where some compilers historically would remove comments, and the exact same schemas (one with comments, one without), would represent different versions of a schema. This means having to register multiple schemas in a schema registry in order to take with it.

With Protobuf, this becomes even worse, where depending on compilation rules you can get exactly the same data representation, but with slight differences (json_name options, comments vs no comments, re-ordering of fields, etc.) across language bindings. Any serious implementation of a protobuf3 schema registry should consider different but exactly equivalent proto3 schemas as having the same ID internally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant