Lexicon Versioning

[jseely]

How to deal with Lexicon versioning came up during the working session during ATmosphere Conf.

Goals of this Issue:

• How do we handle deprecating fields from a lexicon schema
• How do we handle adding new required fields to a lexicon schema
• How does this impact the forward/backward compatibility
• Are there types of lexicons that might be versioned different

[jseely]

A comment that I brought up in the session today was the prior art that we can look at in the Kubernetes ecosystem.

In the Kubernetes ecosystem we version all Custom Resource Definitions (CRDs) by standard but we avoid the complexity faced in the AT Protocol space of decentralized users (in some respects) by having the operator that defines the CRD be responsible for migrating the Custom Resources (CRs) present in a given cluster to the new version as part of a conversion operation.

This option, unfortunately isn't available to us as the AppView does not have centralized control over the data stored on the PDS.

An option brought up during the conversation was to use v >= x notation in AppViews to enable continous function but that still leaves the question of what to do with old data and how to support or deprecate that old data going forward.