Check "enforcecompatibility" capability - does it make sense?

[duglin]

No description provided.

[duglin]

The spec says:

Attempts to change this value from `false` to `true` MUST fail if doing so would result in any
existing Version violating the compatibility rules defined for the owning Resource.

So, I think the concern about the state of the system becoming invalid due to changing this capability is addressed, no? @lailabougria thoughts?

Also, right now this capability is a registry-global flag. Are we still ok with that?

[lailabougria]

In essence it does but something still feels off. When I look at the other capabilities, this seems to be one that has very different kinds of effect on the registry as it requires a full revalidation where others are more "flag"-type settings that don't affect the content of the registry (although maybe specversion would have a similar effect?). EiIt appears like a different beast compared to the other settings.

That also makes me wonder: would it make sense to have a different compatibility strategy per resource, but the resources still registered as part of the same registry? I think that's possible, and in that case it would make more sense on a resource level, which also alleviates the point about this being a different type of setting with very different effects on the registry.

[duglin]

Let's discuss this on tomorrow's call - I do see your point (especially the "just a flag" vs "re-validation" aspect).

[duglin]

Proposal:

• remove enforcecompatibility as a global capability
• define RESOURCE.meta.compatibility:
  • as today, enum/string: https://github.com/xregistry/spec/blob/main/core/spec.md#compatibility-attribute
  • informational purposes only. Statement of what the client believes to be true but server does not verify claim
  • server MAY choose to verify as an extension, and how that works is out of scope of the spec

Open questions:

• if someone did define an "enforcecompatibility" type of flag, how would they know the order of the Versions to perform the checks?

[duglin]

2/19 - @lailabougria will think about how to spec/implement a compat check when there's no mechanism in the spec to know the order of the versions (when sticky is supported).

Might adopt the proposal as "good enough" for v1 but will wait until next week to decide.