In Octez v15.0, the next major release of the Octez suite, the names of executable binaries will change:
- the
tezos-
prefix becomesoctez-
, and; - the protocol number (e.g., the
014
intezos-tx-rollup-node-014-PtKathma
) is removed from protocol-specific executables — baker, accuser, Layer 2 nodes and clients, etc.
These changes have already been implemented in the Octez master
branch, and will be enforced from its first release candidate,
v15.0~rc1
.
The prefix change from tezos-
to octez-
is enacted for consistency
with the name we have given to this specific implementation of
Tezos — the motivation for these changes was described in this blog
post
when Octez was announced to the world. This step is meant to further
clarify that Octez executables are one particular implementation of
Tezos — that is, of everything but the economic protocol itself.
Removing protocol numbers will make it clearer that they are not related to the Octez version numbers. Indeed, some users were confused when Octez adopted the use of version numbers, as they eventually grew to match protocol numbers (although this was the result of a fortuitous coincidence).
Furthermore, removing the protocol number will help clarify why different versions of protocol-specific binaries are shipped with Octez releases, making instructions (specially around protocol upgrades) more precise and less ambiguous. Now, those executables only contain the name of the protocol they target, which should make it clearer that they are a particular implementation, which is part of a specific version of Octez.
Here is the full list of renamings:
tezos-node
becomesoctez-node
.tezos-client
becomesoctez-client
.tezos-admin-client
becomesoctez-admin-client
.tezos-signer
becomesoctez-signer
.tezos-codec
becomesoctez-codec
.tezos-protocol-compiler
becomesoctez-protocol-compiler
.tezos-proxy-server
becomesoctez-proxy-server
.tezos-validator
becomesoctez-validator
.tezos-accuser-014-PtKathma
becomesoctez-accuser-PtKathma
.tezos-accuser-015-PtLimaPt
becomesoctez-accuser-PtLimaPt
.tezos-accuser-alpha
becomesoctez-accuser-alpha
.tezos-baker-014-PtKathma
becomesoctez-baker-PtKathma
.tezos-baker-015-PtLimaPt
becomesoctez-baker-PtLimaPt
.tezos-baker-alpha
becomesoctez-baker-alpha
.tezos-tx-rollup-client-014-PtKathma
becomesoctez-tx-rollup-client-PtKathma
.tezos-tx-rollup-client-015-PtLimaPt
becomesoctez-tx-rollup-client-PtLimaPt
.tezos-tx-rollup-client-alpha
becomesoctez-tx-rollup-client-alpha
.tezos-tx-rollup-node-014-PtKathma
becomesoctez-tx-rollup-node-PtKathma
.tezos-tx-rollup-node-015-PtLimaPt
becomesoctez-tx-rollup-node-PtLimaPt
.tezos-tx-rollup-node-alpha
becomesoctez-tx-rollup-node-alpha
.
Adapting to these changes
We understand that these are breaking changes, which impact possibly years of existing deployment infrastructure and documentation. With this in mind, we have included in Octez v15.0 the following provisions for maintaining backwards compatibility.
When building Octez v15.0 from sources using make
, symbolic links
will be created from the old names to the new names. The list of
symbolic links is exactly the list given above. For instance, a
symbolic file named tezos-baker-014-PtKathma
is created, which
targets octez-baker-PtKathma
. This way, the changes brought in by
Octez v15 should be compatible with, e.g., existing deployment scripts
which rely on the explicit names of previous Octez versions’ binaries.
In the case of Octez Docker images, the transition is slightly less
smooth: When specifying the PROTOCOL
environment variable to choose
which baker and accuser to run, the protocol number must not be
included. For instance, PROTOCOL=PtKathma
must be used instead of
PROTOCOL=014-PtKathma
.
Additionally, there are no symbolic links from the old names to the
new names in the Docker images themselves. However, the entrypoint
script accepts both tezos-
and octez-
prefixed commands. The old
tezos-node
and tezos-baker
commands should still work as before,
although it is now strongly recommended to use the newly added
respective replacement commands, octez-node
and octez-baker
, instead.
In the case of Octez executables downloaded from their release page on GitLab, these static binaries use the new naming conventions. Users will need to either adopt the new names, or create symbolic links themselves.
Note that the old naming convention is now formally deprecated. In a future major release, possibly Octez v16.0, we plan to remove symbolic links as well as the old names for the commands in the Docker image entrypoint. It is thus a good idea to try to migrate to the new naming conventions before Octez 16.0 is out!
If you are unsure about what needs to be done on your end, reach out to us on the Tezos baking Slack or feel free to contact the Nomadic Labs support team.