Sermantic versioning for the protocol, with release candidates

forks
core-devs
consensus-protocols

#1

From my comment in the Jello Paper discussion:

And regarding “release candidates”, copying my comments from AllCoreDevs gitter here:

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”


EIP-233: Formal process of hard forks
#2

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.

https://gist.github.com/jpitts/4c541a4efa2f8872ce9acf63da5c4921


#3

A similar proposal was made back here: https://github.com/ethereum/EIPs/issues/178

It comes with some differences:


Jello Paper as Canonical EVM Spec
#4

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.


#5

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.


#6

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.


#7

FYI, I updated the gist of the protocol releases and EIPs in each.

https://gist.github.com/jpitts/4c541a4efa2f8872ce9acf63da5c4921