This repository was archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
Name/version in runtime #241
Copy link
Copy link
Closed
Labels
J0-enhancementAn additional feature request.An additional feature request.Z3-substantialCan be fixed by an experienced coder with a working knowledge of the codebase.Can be fixed by an experienced coder with a working knowledge of the codebase.
Milestone
Description
This should add an entry to the API that returns a Slicable struct:
struct RuntimeVersion {
spec_name: String, // "polkadot"
impl_name: String, // "parity-polkadot"
authoring_version: u32, // "0"
spec_version: u32, // "0"
impl_version: u32, // "0"
}
The fields have very particular meanings:
spec_nameidentifies the different Substrate runtimes. There'll be at leastpolkadotanddemo. A different on-chainspec_nameto that of the native runtime would normally result in node not attempting to sync further.impl_nameIs the 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 beparity-polkadot. If there were a non-Rust implementation of the Polkadot runtime (e.g. C++), then it would identify itself with an accordingly differentimpl_name.authoring_versionis the version of the authorship interface. An authoring node will not attempt to author blocks unless this is equal to its native runtime.spec_versionis the 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 ofspec_name,spec_versionandauthoring_versionare the same between Wasm and native.impl_versionis the 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 code may be different, it is nonetheless required to do the same thing. Non-consensus-breaking optimisations are about the only changes that could be made which would result in only theimpl_versionchanging.
NOTE: 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.
Metadata
Metadata
Assignees
Labels
J0-enhancementAn additional feature request.An additional feature request.Z3-substantialCan be fixed by an experienced coder with a working knowledge of the codebase.Can be fixed by an experienced coder with a working knowledge of the codebase.