Branch Transitive Compatibility

[wolfchimneyrock]

Feature or Problem Description

Right now for each compatibility mode you can choose whether it tests only against the immediately prior version of an artifact, or to all prior versions using the *_TRANSITIVE compatibility modes.

With the version branches feature now included, would it be possible to have a third type of compatibility that tests against all of the prior version in a given branch? And/or a mode that tests against the latest version of the schema in a given branch / all branches.

This would give us the ability to emulate a mutable registry while retaining immutability:

For example:
branch "1.0" contains versions 1.0.0, 1.0.1, 1.0.2 indicating that there were two mutations to "1.0"
branch "1.1" contains versions 1.1.0, 1.1.1 indicating there was one mutation to "1.1"
creating a branch "1.2" would test compatibility against the newest version in branches "1.0" and "1.1"

[EricWittmann]

This is an interesting take on something we have already discussed internally. As part of our support for semantic versioning, we've been discussing how to apply the compatibility rule when semantic versioning is enabled. Typically, patch releases should be stricter than minor releases, which should be stricter than major releases. We know this is an area of opportunity but haven't designed anything here yet.

It seems to me that your request adds some data to this discussion. I do think we need to document what we think the compatibility algorithm needs to be when using semantic versioning, with this request potentially being part of that.

[wolfchimneyrock]

The proposed use is a migration of a legacy schema registry which allowed mutating versions as long has the version hasn't been "promoted" from development to production.

Major version incompatibility would not be an issue, since the plan would be to suffix the artifactId with the major version - thus different major versions would be different artifacts entirely.

The alternative would be to enable version deletion in our development apicurio instance - but even that has issues unless there is some kind of "atomic swap" operation instead of the two step "delete version" then "create version"

[EricWittmann]

Interestingly I am working on a new version of apicurio studio that will integrate directly with the back end of registry. Part of this work is likely to enable mutability for artifact version content. I wonder if this feature could also help with your use case. You would be able to change the content of a artifact version. But only if mutability is enabled and only if the artifact version is in draft status.