When are you required to change the `authoring_version` for forkless runtime upgrades?

Question

In the Substrate documentation here and the Substrate reference documentation here it says the 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".

In this old pull request for Substrate the authoring_version was incremented for Kusama but I am not clear why that was necessary. It appears to have changed because the following were changed since paint was renamed to pallet and those block authoring related dependencies changed:

• pallet-authorship used instead of paint-authorship
• pallet-authority-discovery used instead of paint-authority-discovery
• pallet-babe used instead of paint-babe

Note that the babe pallet is used for authoring blocks, the authorship pallet is used to fetch the current block author and to create and submit unsigned extrinsics, and the authority-discovery pallet is used to "retrieve the current set of authorities".

Another situation when I think it should change is if you changed consensus mechanism, for example this old pull request here for the DataHighway changed it from Babe to Aura, but I think it was incorrect that they (me) did not change the authoring_version.

In the Substrate reference documentation here for can_author_with, instead of checking the authoring_version, it checks here if the "authoring runtimes (spec_versions) that this native runtime supports" matches the other version that is provided to determine whether it supports authoring blocks, where the other version may be associated with the version provided for a forkless runtime upgrade, which leads me to think that the spec_version would typically get bumped alongside an authoring_version bump.

It also says in the Substrate source code here that "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". I assume that means the authoring_version would only need to be incremented in the case of a bug fix or other change related to block authoring dependencies.

In the Substrate source code here it says that "Per convention: if the runtime behavior changes, increment spec_version and set impl_version to 0. If only runtime implementation changes and behavior does not, then leave spec_version as is and increment impl_version.". I assume that the convention also requires that for changes related to authorship then when the runtime behaviour changes but the implementation does not change then you either increment authoring_version or set authoring_version to 0. I am not sure what they mean when they say runtime "behavior".

Answer 1

The idea behind authoring_version was to indicate that something in the api between the runtime and the node changed that makes the node unable to build new blocks. We almost never bumped this version and with the removal of the native runtime this authoring_version will probably be deprecated anyway. If you break something in the authoring interface like apply_extrinsic you would probably find it out anyway by having the block production fail ;) Currently it would spam your logs with "node upgrade" required.

TLDR: Set the version to some sane value like 1 for now. We will need to have some more discussion on the future of this authoring_version and if we maybe deprecate it or change it and improve the documentation on when to bump this.