Announcing Octez v25.0

Project Updates
1

:megaphone: Octez version 25.0 has just been released!

Octez v25.0 includes the following changes:

  • Protocol support for Ushuaia. Version 25 is compatible with all protocols that depend on a protocol environment version up to V16. That includes the Ushuaia protocol proposal, which is currently undergoing the Adoption period of the on-chain governance mechanism.

As a reminder, the Ushuaia protocol upgrade will activate on Tezos mainnet at the end of cycle 1277, expected on June 29th.

  • Deprecation of Octez Ubuntu/Debian distribution packages. Starting with v25, installing Octez Debian/Ubuntu binary distribution packages will display a deprecation warning. Linux distribution packages will be removed in v26.
    The experimental octez-manager tool (see https://octez-manager.tezos.com) handles installation, configuration, and deployment of static binaries in a more user-friendly way. This tool is in early development and should be used for testnets only for now.

  • Baker: removal of the adaptive issuance vote. Octez v25 removes the --adaptive-issuance-vote CLI option and the adaptive_issuance_vote field from per_block_votes.json. Both were deprecated in v24 and have no effect since Paris activated Adaptive Issuance. If your per_block_votes.json still contains adaptive_issuance_vote, the v25.0 baker will reject it at startup. Please remove that field before upgrading.

Additionally, v25.0 includes the following changes compared to v25.0~rc1:

  • RPC client bugfix. Fixed a file descriptor leak: connections opened for HTTP redirects were never released, affecting all Octez executables issuing RPC calls through an endpoint with redirects (e.g., behind a reverse proxy).

  • DAL node. Added a --skip-shards flag to the snapshot export and snapshot import commands. When set, shards are neither exported nor imported, producing smaller snapshots for nodes that only need slot data.

:package: Distribution details

5 Likes
Lets get ready for Ushuaia!
2

Note on Ubuntu packages

Starting from Octez v25, the Ubuntu APT repository is named after the

distribution version number instead of its codename:

  • ubuntu/jammy becomes ubuntu/22.04

  • ubuntu/noble becomes ubuntu/24.04

  • ubuntu/26.04 is newly supported

If you installed Octez v24 (or earlier) from the APT repository, the old

codename-based path is no longer updated. Running apt-get update and

apt-get upgrade will therefore not upgrade you to v25 until you repoint the

repository to the new version-number-based path.

To upgrade, set the release to your Ubuntu version number and re-add the
repository:

  export distribution=ubuntu
  export release=24.04  # or 22.04, 26.04

then follow the install instructions to refresh

/etc/apt/sources.list.d/octez.list, and finally run::

  sudo apt-get update
  sudo apt-get upgrade

Debian users are not affected: the Debian repository keeps using codenames

(debian/trixie, debian/bookworm).

1 Like
Lets get ready for Ushuaia!
3

Hello,

I am writing to discuss the end of support for Octez distribution packages for Ubuntu/Debian starting with version 26.

I think Octez Manager looks like a very good project for new installations and for users who are new to baking. Having a single tool that installs, configures and manages the whole stack will probably make onboarding much easier.

However, I’m not convinced it is the right replacement for existing production setups.

Many long-time bakers already have stable, well-tested infrastructures that have evolved over the years. In my case, I run my baker inside an LXC container without udev or systemd. My node is behind CGNAT, and my DAL node is reached through a WireGuard tunnel running in another LXC connected to a server with a public IPv4 address. I have a simple tmux session with multiple panes tailing the logs of the node, baker and DAL node simultaneously. Everything is immediately visible and easy to troubleshoot. Personally, I don’t feel the need for another management layer on top of that.

My concern is that Octez Manager may not adapt well to all of the “non-standard” environments that many experienced operators use. LXC containers, custom networking, external orchestration, manual service management, or environments without a full systemd installation are not unusual in the Linux world.

From my perspective, replacing native Debian packages with an all-in-one tool installed via curl | sh feels like a step backwards. Debian packages integrate naturally with the operating system, package manager, configuration management tools and automation workflows. They are predictable, easy to audit, and fit well into existing infrastructure. Updating through the Debian package manager is simple. A quick apt update && apt upgrade is all that’s needed, and it integrates seamlessly with the rest of the system. I don’t think this workflow can realistically be made any simpler.

Would it be possible to keep the Debian packages available in parallel with Octez Manager?

This would allow new users to benefit from the simplified experience while letting existing operators continue using the deployment model that has been working well for years. I don’t see these two approaches as competing with each other, they seem complementary and could serve different audiences.

4

Good news!

1 Like