Default value changes across schemas are not considered backwards incompatible

[sdboyer]

The following lineage (in new flattened form, and omitting lenses) should be invalid:

name: "defaultchange"
schemas: [
    {
        version: [0, 0]
	schema: {
	    aunion: *"foo" | "bar" | "baz"
        }
    },
    {
        version: [0, 1]
	schema: {
	    aunion: "foo" | *"bar" | "baz"
        }
    },
]

But the new BindLineage() does not complain.

Conversely, the following lineage should be valid:

name: "defaultchange"
schemas: [
    {
        version: [0, 0]
	schema: {
	    aunion: *"foo" | "bar" | "baz"
        }
    },
    {
        version: [1, 0]
	schema: {
	    aunion: "foo" | *"bar" | "baz"
        }
    }
]

But it is not, saying instead:

error binding lineage: schema 1.0 must be backwards incompatible with schema 0.0

[sdboyer]

FWIW i have known this issue exists for quite some time. I tried a number of different ways of resolving it in the past, and iirc, explicitly close()-ing the schemas like this:

name: "defaultchange"
schemas: [
    {
        version: [0, 0]
	schema: {
	    aunion: *"foo" | "bar" | "baz"
        }
    },
    {
        version: [0, 1]
	schema: close({
	    aunion: "foo" | *"bar" | "baz"
        }
    },
]

and changing some of the parameters we pass to cue.Value.Subsume() resulted in the desired behavior. However, requiring an explicit close() to be written by the user in order for thema to provide invariants effectively makes them not invariants at all. That's a non-starter.

[joanlopez]

I'm curious, why this change on the default value should be considered backwards incompatible?
I cannot clearly see the reason why 🤔

[verdverm]

another interesting case to consider, where changing the default may still be considered to be backwards compatible (?)

v1. aunion: float | *int

v2. aunion: float | int | *1

In this case, the newer default is more specific, but still compatible.

---

@joanlopez I believe the answer lies in the foundations of the CUE lattice and subsumption, and using that as the definition of backwards compatibility. https://cuelang.org/docs/concepts/logic

[joanlopez]

@joanlopez I believe the answer lies in the foundations of the CUE lattice and subsumption, and using that as the definition of backwards compatibility. https://cuelang.org/docs/concepts/logic

Does that mean, following the initial examples, that v0.1 couldn't be a subsume of v0.0 (or the opposite), and therefore there's no backwards compatibility (there's a breaking change)?

In any case, thanks! @verdverm :)