Versioning concerns several components of Octez. This page explains the various corresponding versioning schemes, which are mostly independent of each other. Though, some relations do exist (e.g. when a new protocol is proposed, a new Octez release is usually delivered embedding the new proposal, for convenience); this is explained in some versioning schemes.
Protocol environment versions¶
The economic protocol can interact with the rest of the Octez software through a sandboxed API called a protocol environment. When new features are needed by a proposed protocol, a new environment version is created, see Protocol environment versions. The new environment is delivered as part of a new Octez release.
In Octez, RPCs can be versioned using a query parameter called
version. This query parameter exists only for RPCs which have at
least two different versions. For example:
./tezos-client rpc get /chains/main/mempool/pending_operations?version=0
If the RPC is called with a bad version number (a negative or an unsupported version) the call fails with an error message like:
Fatal error: Command failed: The RPC was called with version number '2' which is not supported. Version numbers accepted are '0, 1'.
For technical reasons, the default version number of an RPC cannot be retrieved easily yet.
Added version 5 to RPC GET chains/main/mempool/pending_operations. It can be used by calling the RPC with the parameter ?version=5 (default version is still 4).
New Default Version¶
Whenever an Octez release changes the default version of an RPC, there is a corresponding entry in the file CHANGES.rst.
The default version for RPC GET chains/main/mempool/pending_operations is now 5 (previously 4). You can still use the previous version by calling the RPC with the parameter ?version=4.
As a general rule (that we may break exceptionnaly), changing the default version number of an RPC always follows a deprecation period.