Runtime versioning scheme

[chevdor]

Here is a proposal for a new versioning scheme for the runtime. It is critical for client API that the runtime versioning keeps increasing. We also don't want increasing versions from a chain to conflict with versions of another chain.

So far:

• the client versions have been "somehow" hinted in the runtime version
• the chain can be identified in the runtime version

Assuming the client use semver and that we want to keep room for double digit minor versions and patches (such as 0.10.02).

NOTE: Runtimes will likely not be kept in sync and will not be updated as often as clients but keeping the numbers in sync allows keeping client and runtime roughly in sync. In practice, that means the runtime versions will jump. For example, we will see clients 1.2.3, 1.2.4, 1.2.5, 1.3.0 but the runtime will be bumped a single time and that will likely not be from N to N+1.

scheme on 10 chars

<SSSS><MM><mm><pp> with:

• SSSS: SS58 coded in hex (0000..FFFF)
• MM: major
• mm: minor
• pp: patch

Examples:

• V002A001001 for Westend (42 = 0x002A) matching client 0.10.01
• V0001000902 for Polkadot (01= 0x0001) matching client 0.9.2
• V0002121314 for Kusama (02= 0x0002) matching client 12.13.14

Using the SS58 prefix allows each chain to manage their runtime numbering as they wish with the only requirement to prefix with their SS58 prefix.

While the format is more verbose than the current (ie 0001000902 vs 30), it can be displayed in a lighter form such as Kusama Runtime V 0.9.2.

[JoshOrndorff]

The SS58 prefix scheme has changed to 16 bits in https://github.com/paritytech/substrate/pull/8955

So this would have to be extended to a scheme on 10 chars, right?

[chevdor]

Thanks @JoshOrndorff, indeed. I updated the proposal.