import { type known } from "https://deno.land/x/capi@v0.1.1-beta.1/mod.ts";
const { RuntimeVersion } = known;
Runtime version.
This should not be thought of as classic Semver (major/minor/tiny).
This triplet have different semantics and mis-interpretation could cause problems.
In particular: bug fixes should result in an increment of spec_version and possibly
authoring_version, absolutely not impl_version since they change the semantics of the
runtime.
Properties
Identifies the different Substrate runtimes. There'll be at least polkadot and node. A different on-chain spec_name to that of the native runtime would normally result in node not attempting to sync or author blocks.
Name of the implementation of the spec. This is of little consequence for the node
and serves only to differentiate code of different implementation teams. For this
codebase, it will be parity-polkadot. If there were a non-Rust implementation of the
Polkadot runtime (e.g. C++), then it would identify itself with an accordingly different
impl_name.
authoring_version is the version of the authorship interface. An authoring node
will not attempt to author blocks unless this is equal to its native runtime.
Version of the runtime specification. A full-node will not attempt to use its native
runtime in substitute for the on-chain Wasm runtime unless all of spec_name,
spec_version and authoring_version are the same between Wasm and native.
Version of the implementation of the specification. Nodes are free to ignore this; it
serves only as an indication that the code is different; as long as the other two versions
are the same then while the actual code may be different, it is nonetheless required to
do the same thing.
Non-consensus-breaking optimizations are about the only changes that could be made which
would result in only the impl_version changing.
All existing dispatches are fully compatible when this number doesn't change. If this
number changes, then spec_version must change, also.
This number must change when an existing dispatchable (module ID, dispatch ID) is changed, either through an alteration in its user-level semantics, a parameter added/removed/changed, a dispatchable being removed, a module being removed, or a dispatchable/module changing its index.
It need not change when a new module is added or when a dispatchable is added.