Title: Sermantic_versioning_for_the_protocol__with_releas
Category: Magicians

Author: jpitts
Date: 2019-01-21T16:48:40.242Z

From my comment in the  Jello Paper discussion:



Jello Paper as Canonical EVM Spec

One notion that I arrived at is that the protocol should itself have semantic version, and that its component parts, i.e. the EVM, consensus, RLP, JSON-RPC, each should have semantic versions. Within their various contexts, the versioning changes would have different meaning.
Semantic Versioning 2.0.0
Ethereum protocol would increment MAJOR when the update to any of its components leads to a fork.
EVM would increment MAJOR only if the update leads to incompatibility or security vulnerability (given contract development norms). MAJOR version increments in EVM is similar to a new series in microprocessors. But MINOR version increments in the EVM would lead to a MAJOR increment at the protocol level.


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”

Author: jpitts
Date: 2019-01-21T19:01:59.706Z

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

Author: axic
Date: 2019-01-21T21:02:04.739Z

A similar proposal was made back here: https://github.com/ethereum/EIPs/issues/178
It comes with some differences:

only considers EVM,
because of this goes well with https://github.com/ethereum/EIPs/issues/154,
only uses major/minor in order to save space

Author: axic
Date: 2019-01-21T21:05:46.137Z

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.

Author: jpitts
Date: 2019-01-21T21:13:37.465Z

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.

Author: jpitts
Date: 2019-01-23T08:51:37.065Z

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.




GitHub



Release Version 0.4.21 · ethereum/solidity
We again introduced several changes that are scheduled for version 0.5.0 and can be activated using pragma experimental "v0.5.0";. In this release, this pragma does not generate a warning anymore, ...

Author: jpitts
Date: 2019-01-23T08:57:33.044Z

FYI, I updated the gist of the protocol releases and EIPs in each.
https://gist.github.com/jpitts/4c541a4efa2f8872ce9acf63da5c4921