[Meta] Versioning System

[willwarren89]

Summary

Establishes a versioning system that may be used to assign and increment 0x protocol version numbers.

Motivation

0x protocol consists of (1) a standard message format that describes how to specify the details of a proposed trade and (2) a modular pipeline of Ethereum contracts that accepts and processes these messages. Protocol updates involve adding, replacing, or modifying the internal state of individual Ethereum contracts within the 0x pipeline. This proposal aims to establish a versioning system for 0x protocol that characterizes how different types of updates impact third party Ethereum contracts and dapps.

Specification

The version number will be bumped anytime an Ethereum contract is added to the 0x pipeline, an existing contract is replaced, or a modification is made to an existing contract's access controls.

Proposal 1: Semantic Versioning

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible Ethereum contract ABI changes:
  • replacing the Exchange contract.
• MINOR version when you add functionality in a backwards-compatible manner:
  • adding a new AssetProxy contract and registering the associated AssetProxyId with all upstream contracts (Exchange, utility AssetProxy contracts such as MAP).
  • adding a new contract that sits between the Exchange and AssetProxy contracts by registering the new contract's AssetProxyId with all upstream contracts AND registering the new contract as an authorized caller for all downstream AssetProxy contracts.
  • replacing the AssetProxyOwner contract.
• PATCH version when you make backwards-compatible bug fixes.
  • removing deprecated contracts from the pipeline.

Semantic versioning specifies that 'Patch and minor version MUST be reset to 0 when major version is incremented'. Given the modular nature of the 0x pipeline and the above specification, a pipeline that includes ExchangeV2, ERC20AssetProxy, ERC721AssetProxy, and MultiAssetProxy contracts should be 0x v2.3.0. If we were to hook an ExchangeV3 contract into the three existing AssetProxy contracts, this new branch of the pipeline would be 0x v3.3.0. Both versions of the protocol could run in parallel.

Proposal 2:

Alternatively, the version number could somehow relate to the set of possible paths that one may traverse down the pipeline, starting from the inlet (Exchange contract). Not sure exactly how this would work, but ideally it provides intuition around how the system fits together.

ExchangeV3 <=> {ERC20AssetProxy, ERC721AssetProxy}
ExchangeV3 <=> MAP <=> {ERC20AssetProxy, ERC721AssetProxy}