COMPATIBILITY rule for OpenAPI

[kolchanov]

Hello,
I'm evaluating apicurio for open apis and i'm confused with compatibility rules.
Scenario:

1. Create simple OpenAPI. F.e. airport codes from https://cloud.google.com/endpoints/docs/openapi/openapi-overview
2. Create new version with modified required parameter name

I'm expecting that compatibility rule does't allow me create this version

[kolchanov]

I found answer myself.

Not all content rules are fully implemented for every artifact type supported by Apicurio Registry. The following table shows the current maturity level for each rule and artifact type.

[EricWittmann]

Yep - you got the answer! Implementing compatibility for OpenAPI is high on our bucket list. Just hasn't been done yet.

[svenmathijssen]

Any update on this? Is it still somewhere high on the bucket list? :) We are currently implementing a complicated service mesh that has a need for correct implementation of compatibility constraints in order to do version management correctly.

[EricWittmann]

This is still on the bucket list, yes. And we've had some discussions on it - not just within Red Hat but also with some of our peers at IBM who work in this same space. The problem is actually quite tricky, and we honestly haven't made a ton of concrete progress.

One example of where things get tricky is that the JSON Schema definitions (e.g. defined within components) can be used either as inputs or as outputs (or both) for various operations. Compatibility rules will be different for inputs vs. outputs.....

So it's stuff like that - nothing insurmountable but also dicey compared with the formats we currently do support.

Probably we should just create something ASAP and iterate through the issues until we arrive at a reasonable solution. Just haven't had the bandwidth for that yet.