Add section about EVM version and explain its implications

[axic]

It should mention:

• the different versions and what different behaviour is introduced with each,
• the default version used
• implications in private chains

[chfast]

I'm not sure you like it, but we are using "EVM revision" name in EVMC to enumerate hard fork changes.

[axic]

I'm not sure how much it matters (need to see the section written up), but the fact is the flag is called currently evmVersion (in JSON) or --evmversion (on CLI) so probably makes sense using this wording to avoid confusion.

[ChrisChinchilla]

@axic

Can I find most of the details needed to meet what's needed in the various referenced issues and PRs?

And Is this also made against develop, or a different branch?

[axic]

Can I find most of the details needed to meet what's needed in the various referenced issues and PRs?

The references PRs don't really add too much, they are different issues all caused by not compiling the contract for the right EVM version.

What needs to be added is:

• the compiler has an option to select the target EVM version
• must list the target options and state the default is byzantium
• should add it into the standardjson documentation and the cli documentation

And Is this also made against develop, or a different branch?

All of it should be against develop.

[ChrisChinchilla]

@axic To check, the top comments says:

the different versions and what different behaviour is introduced with each,
implications in private chains

The latest one doesn't. Still want those too?

[axic]

Sure, all of this detail is useful. Practically it is one sentence: compiling for the wrong EVM version likely can result in wrong, strange and failing behaviour. Please ensure, especially if running a private chain, that the correct EVM version is used. Note: there might be cases where backwards compatibility exists between different EVM versions, but deducting that is the onus of the user.