implement replacement for schemas

[propensive]

I want to replace schemas with "variants" to better represent the nature and structure of what they're intended to represent.

There will now be a single "base" or "default" layer, with projects defined immediately beneath it. This means removing the additional level of indirection which is the schemas collection, and storing projects directly inside layers.

There will be a new variants collection on layers which will contain a mapping from variant names (such as scala-2.11) to a diff between the current layer and the "variant layer". That diff will be stored as the changes to the OGDL-serialized format used to represent a layer. That means that we don't need to store each layer more than once, and means that we can efficiently store differences between anything that's serializable to OGDL (i.e. anything in the layer) without needing to worry about having complex types to represent differences between all our different datatypes. This would only be a storage format, though. In normal usage, both the base layer and a variant of it would be represented as instances of Layer, the variant being reconstituted by applying the diff to a base layer.

Note that variants now form a tree, and we can have variants of variants.

I propose to reference variants relative to a layer using the @ symbol, for example,

• fury://furore.dev/scala/[email protected]
• scala/[email protected]
• //DBCFF6BC03@js/2.12

Now, any change to a parent layer might result in warnings if those changes are overridden by changes in the variants. This should help with maintenance, and making users more aware of changes which affect other branches in the tree of variants.

[propensive]

Replaces #759

[odisseus]

If the variants are to be stored as diffs to the base layer, these diffs may become not applicable after the base layer changes.

By the way, do the schemas have any other use besides switching compiler versions?

[propensive]

The intention is that any changes which change the nature of the diffs (i.e. they change something different from what they changed before, or they try to change something which doesn't exist) would result in errors or warnings for that change. There's a lot of scope for trying to make this intuitive through the user interface, though I certainly wouldn't want to assume that a base layer could be modified whilst ignoring any variations derived from it.

The schemas, and equally the variants, would be intended to store any change. Most likely that would be major Scala version, but it could also be used for minor Scala versions, different backend targets, or including or excluding certain dependencies.

I'm further contemplating the idea of allowing users to combine different combinations of variants, making them more like "tags", provided no two variants being applied try to modify the same details in the layer. I'll work out the details on this, but I think it's possible, and it could be very powerful.