1. Research & development
  2. > Blog >
  3. Announcement: New Names for Octez Executables in v15.0

Announcement: New Names for Octez Executables in v15.0

11 October 2022
Nomadic Labs

In Octez v15.0, the next major release of the Octez suite, the names of executable binaries will change:

  • the tezos- prefix becomes octez-, and;
  • the protocol number (e.g., the 014 in tezos-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 becomes octez-node.
  • tezos-client becomes octez-client.
  • tezos-admin-client becomes octez-admin-client.
  • tezos-signer becomes octez-signer.
  • tezos-codec becomes octez-codec.
  • tezos-protocol-compiler becomes octez-protocol-compiler.
  • tezos-proxy-server becomes octez-proxy-server.
  • tezos-validator becomes octez-validator.
  • tezos-accuser-014-PtKathma becomes octez-accuser-PtKathma.
  • tezos-accuser-015-PtLimaPt becomes octez-accuser-PtLimaPt.
  • tezos-accuser-alpha becomes octez-accuser-alpha.
  • tezos-baker-014-PtKathma becomes octez-baker-PtKathma.
  • tezos-baker-015-PtLimaPt becomes octez-baker-PtLimaPt.
  • tezos-baker-alpha becomes octez-baker-alpha.
  • tezos-tx-rollup-client-014-PtKathma becomes octez-tx-rollup-client-PtKathma.
  • tezos-tx-rollup-client-015-PtLimaPt becomes octez-tx-rollup-client-PtLimaPt.
  • tezos-tx-rollup-client-alpha becomes octez-tx-rollup-client-alpha.
  • tezos-tx-rollup-node-014-PtKathma becomes octez-tx-rollup-node-PtKathma.
  • tezos-tx-rollup-node-015-PtLimaPt becomes octez-tx-rollup-node-PtLimaPt.
  • tezos-tx-rollup-node-alpha becomes octez-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.