Discuss: Move away from semver for protocol versioning

We have discussed this in various contexts. I believe the discussion deserves larger visibility.

I documented my rationale in the Ethereum 2.0 networking spec. Copying (with editorial fixes):

Why do we version protocol strings with ordinals instead of semver?

Using semver for network protocols is confusing. It is never clear what a change in a field, even if backwards compatible on deserialisation, actually implies. Network protocol agreement should be explicit. Imagine two peers:

• Peer A supporting v1.1.1 of protocol X.
• Peer B supporting v1.1.2 of protocol X.

These two peers should never speak to each other because the results can be unpredictable. This is an oversimplification: imagine the same problem with a set of 10 possible > versions. We now have 10^2 (100) possible outcomes that peers need to model for. The resulting complexity is unwieldy.

For this reason, we rely on negotiation of explicit, verbatim protocols. In the above case, peer B could provide backwards compatibility by supporting and advertising both v1.1.1 and v1.1.2 of the protocol.

Under this scenario, semver would be relegated to convey expectations at the human level, and it wouldn't do a good job there either, because it's unclear if "backwards-compatibility" and "breaking change" apply only to wire schema level, to behaviour, state machine, etc.

Therefore, we remove semver out of the picture and replace it with ordinals that require explicit agreement, and do not mandate a specific policy for changes.

I'm personally for this change. Curious to hear from others.

Read the rationale copied from the Ethereum 2.0 networking spec PR #1328 and review the four-comment discussion. Before implementation, reach agreement on whether protocol version strings should use explicit ordinals instead of semver and define the affected specifications and acceptance criteria; the issue names no files or tests.