radicle-registry-cli is linked against a specific version of
radicle-registry-client which is in turn linked against a specific version of the registry runtime. For users of the CLI this leads to compatibility issues if the on-chain runtime of the network the CLI interacts with does not match the CLI’s runtime version.
With respect to the compatibility we want to achieve the following:
- The CLI should be compatible with as many runtime versions as possible
- The CLI should give meaningful errors if it is incompatible with the runtime
(The same goals can be formulated for the client library. For now we’ll concentrate on the CLI which will tell us more about the requirements for the client library. We can then collect more requirements from the application team and design a solution for client-runtime compatibility.)
The contract between the CLI and the runtime consists of the transaction types and the storage types (and their storage mechanism). Any change to these may result in incompatibility between the CLI and the runtime. I’ll provide more details and examples on this in a follow-up post.
As a baseline solution I suggest we tackle (2) very narrowly first. This solves the immediate problem that incompatibility is currently not properly detected and may result in the CLI working with garbage data or raising unrelated errors. Once we learn more about the compatibility we can extend the compatibility range. Concretely, I suggest that the CLI will ask the node what runtime version is active and abort if the spec version is different from the version the CLI was compiled with.