Protocol updates could follow the practice of “release candidate” within the semantic numbering scheme. And these clever release names, this is over-arching for the upgrade initiative and sticks once it stabilizes on mainnet. Constantinople is what you are attempting to get mainnet to.
So what you attempted to release was ethereum-8.0.0-rc1, released to the testnets and prepared for mainnet. An issue was found, therefore rc1 was aborted. The main network remains at ethereum-7.x.x. Now you proceed with ethereum-8.0.0-rc2, first on ropsten, etc, and then attempt to release to mainnet.
The “release candidate” approach allows you to keep attempting to get from 7.x.x to 8.0.0, by incrementing the x in 8.0.0-rcx. It allows you to not have to worry about the name, which is marketing and communication to the wider community. Once a stable rc-x happens on mainnet, well, IMO that is what becomes “Constantinople”
Here’s a gist depicting what the versions of the protocol would look like, only a sketch. The rc1 and rc2 of Constantinople should have notes about which testnets they were released to, accurate representation of EIP changes, etc.
Because it only considers the EVM, the versions are a bit different - as an example the “DAO fork” doesn’t have a version.
Another question to consider if it is only for the EVM whether gas changes warrant a major version bump. Before gas changes (Spurious Dragon?) were added, it seemed as if gas cannot be changed. After that point though it felt like gas values cannot be relied on and are not to be considered a constant in contract development.
If gas costs are not considered, the version table looks quite differently.
Thanks for the reference! I think that this could be used for advancing the version of the EVM component in a way that dapp developers can understand. Also it can inform how other protocol components might be versioned.
It should be noted that in version 0.4.21, Solidity itself began to allow for the targeting of an EVM “version”.
Do developers have a difficult time knowing which EVM-related EIPs are included in these code-named releases?
you can now specify which EVM version the contract should be compiled for. Valid values are “homestead”, “tangerineWhistle”, “spuriousDragon”, “byzantium” (the default) and “constantinople”. Depending on this setting, different opcodes will be used in some cases. The only place where this is currently used by default is that all gas is forwarded with calls starting from “tangerineWhistle” (in homestead, some gas has to be retained for the call opcode itself). Also, the gas estimator reports different costs for the opcodes depending on the version and thus the optimizer might generate different code.