# Announcing Octez v25.0
**URL:** https://forum.tezosagora.org/t/announcing-octez-v25-0/7114
**Category:** Project Updates
**Created:** [June 16, 2026, 3:06pm UTC](https://forum.tezosagora.org/t/announcing-octez-v25-0/7114 "2026-06-16T15:06:16Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@NomadicLabs](https://forum.tezosagora.org/u/NomadicLabs)
#### Post date: [June 16, 2026, 3:06pm UTC](https://forum.tezosagora.org/t/announcing-octez-v25-0/7114/1 "2026-06-16T15:06:17Z")
đź“Ł 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](https://tzkt.io/13857888), 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](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.
📦 **Distribution details**
- Full changelog and update instructions: [Version 25.0 — Octez & Protocol products documentation](https://octez.tezos.com/docs/releases/version-25.html)
- Assets are available on the releases page: [Octez releases](https://octez.tezos.com/releases/)
- Git tag: `octez-v25.0`
- Commit hash: `187a915b`
---
### Author:  [@NomadicLabs](https://forum.tezosagora.org/u/NomadicLabs)
#### Post date: [June 17, 2026, 4:06pm UTC](https://forum.tezosagora.org/t/announcing-octez-v25-0/7114/2 "2026-06-17T16:06:10Z")
**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:
```auto
export distribution=ubuntu
export release=24.04 # or 22.04, 26.04
```
then follow [the install instructions](https://octez.tezos.com/docs/introduction/howtoget.html#ubuntu-and-debian-octez-packages) to refresh
`/etc/apt/sources.list.d/octez.list`, and finally run::
```auto
sudo apt-get update
sudo apt-get upgrade
```
Debian users are not affected: the Debian repository keeps using codenames
(`debian/trixie`, `debian/bookworm`).
---
### Author:  [@neves-0](https://forum.tezosagora.org/u/neves-0)
#### Post date: [August 3, 2026, 4:44pm UTC](https://forum.tezosagora.org/t/announcing-octez-v25-0/7114/3 "2026-08-03T16:44:46Z")
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.
---
### Author:  [@Primate411](https://forum.tezosagora.org/u/Primate411)
#### Post date: [August 3, 2026, 4:51pm UTC](https://forum.tezosagora.org/t/announcing-octez-v25-0/7114/4 "2026-08-03T16:51:16Z")
Good news!
>
---
### Author:  [@neves-0](https://forum.tezosagora.org/u/neves-0)
#### Post date: [August 5, 2026, 9:29pm UTC](https://forum.tezosagora.org/t/announcing-octez-v25-0/7114/5 "2026-08-05T21:29:48Z")
Fantastic! Thanks for your work!
---
### Author:  [@Primate411](https://forum.tezosagora.org/u/Primate411)
#### Post date: [August 5, 2026, 9:46pm UTC](https://forum.tezosagora.org/t/announcing-octez-v25-0/7114/6 "2026-08-05T21:46:58Z")
Forward all thanks to @chrispinnock 🫶
---
### Author:  [@chrispinnock](https://forum.tezosagora.org/u/chrispinnock)
#### Post date: [August 6, 2026, 7:38am UTC](https://forum.tezosagora.org/t/announcing-octez-v25-0/7114/7 "2026-08-06T07:38:00Z")
Will continue to support these for the foreseeable future. I’m using them for TF and personal work too.