I'm a little confused by this change, I understand authoring_version being set to 12, but why is spec_version set to 6? Shouldn't the spec_version reset to 0 if the authoring_version changes? And if so, I understand we would have:

• spec_version: 0 for Frozen/Thawn
• spec_version: 1 for Supervised
• spec_version: 2 for Liberated
• spec_version: 3 for post-liberated (?) (like enabling bounties etc.)

Is true we have always reset spec version back to 0 on new chains and bumping the authoring version.
I think this was not the right approach, if you observe substrate/polkadot/kusama runtime spec versions they always increment, even when they were going through staging/testnets.

Another reason to always increment is because of a suspicion I have about how polkadot-js/app and extension detects new metadata updates seems to be dependent on spec version (as well as chain name) so it seems safer to not return to older spec versions at least.

Am I overthinking this?

Ok, I'm not very familiar with how polkadot{js} extension works, so perhaps it is safer to not reuse spec_versions.
But if we're trying to predict what number will be correct if we always increment by 1 it becomes hard to manage I think.
Polkadot/Kusama seems to use the approach where spec_version is the version that matches the "release version", like v0.9.29 => 9290 etc., perhaps we should use a similar approach?

Something like {chain_version}.{release_version}.{minor_version} with 00.00.00 semantic, so for example Carthage could start with 120000, then last stage of Carthage would be 120002 (liberated), then mainnet starts from 130000, then 130002 would be liberated, 130100 could be the next major release after mainnet, like Ephesus etc.

Actually now that I think about this, it's probably better to keep the current versioning for Carthage, but just start this spec versioning on mainnet with 10000?

I like your suggestion. A while back I considered a similar scheme, even tried to find a workable scheme that takes into account different runtime profiles (staging, testing, production). The gist was that production runtime starts at high number, and the others at low numbers. This would prevent you from accidentally doing a runtime upgrade to a different profile since system::set_code prevents upgrading to a runtime with lower spec version.

We've been following a convention for release and runtime cargo.toml versioning for the github release also: https://github.com/Joystream/joystream/releases

# Follow convention: https://github.com/Joystream/substrate-runtime-joystream/issues/1
# {Authoring}.{Spec}.{Impl} of the RuntimeVersion
version = '12.1000.0'

Shall we stick with this, and start mainnet spec version at 1000 ?

My main question in this case is what would be the semantics of {Spec}?
Would it be like {SpecMajor}.{SpecMinor}.{SpecPatch}, with 1000 meaning 1.00.0?
So let's say:

• 12.1000.0 is frozen mainnet
• 12.1010.0 is supervised mainnet
• 12.1011.0 could be some supervised-stage hotfix for example
• 12.1020.0 is liberated mainnet
• 12.1030.0 is post-liberated mainnet
• 12.2000.0 is Ephesus (to signify it's a major release an also allow us not having to predict how many other smaller upgrades / patches there will be between mainnet and Ephesus)

I think this should work

Yes that looks like a nice scheme. Double checked that type of spec_version, is at least u32 so we don't run into problems.