ENSDb Schema Versioning

[tk-o]

The goal for this change is to be able to disconnect the version number of ENSApi from the version number of ENSIndexer.

In other words:

• Many versions of ENSIndexer may output data in a stable ENSDb format version.
• Many versions of ENSApi may be comfortable to read data in a stable ENSDb format version.

It's only when we make some breaking change to the ENSDb schema definitions that ENSDb Schema version should be bumped.

[lightwalker-eth]

@tk-o Maybe we call this idea something like the "ENSDb Metaschema Version" to help distinguish it from the ensdb-sdk package version.

Each ensdb-sdk package version will only work with a single "ENSDb Metaschema Version", but multiple ensdb-sdk package versions might know how to work with the same "ENSDb Metaschema Version".

I'm not in love with the word "Metaschema" but not sure of a better idea? It's not a "Schema" because doesn't it depend on multiple distinct schemas?

In my mental model, whenever something changes about any of the following schemas, we would need to bump the "ENSDb Metaschema Version".

• ENSIndexer Schema
• ENSNode Schema

For now we aren't exposing anything with the Ponder Schema, so perhaps we can separate that for now but in theory it might be added to this consideration in the future.

I would be in favor of representing this value as a simple non-negative integer that we begin with 0 and increment across time, rather than a string such as "1.2.3". Every change to the "ENSDb Metaschema" is a breaking change.

[tk-o]

Maybe we can rename "ENSDb Metaschema Version" to "ENSDb Root Schema Version". The Root Schema definition consists of the "abstract" ENSIndexer Schema definition and ENSNode Schema definition. What do you think about this idea?

[tk-o]

@lightwalker-eth as discussed, we won't be adding the const to track the ENSDb Schema version. Instead, we will maintain the ensdb-schema package. Details to be finalized early in April.