Octez releases include all the software needed to run the distributed consensus platform with its meta-consensus capability. This meta-consensus capability is supported by a protocol that is used to achieve consensus not only about the state of its ledger, but also about upgrading the protocol itself, subject to an on-chain voting procedure. This evolving nature of the protocol implies that at each point there are several important protocols, including a currently active protocol (on the main Tezos network) and other protocols under test, development, or being voted on-chain. Thus, protocols are versioned independently from releases (see Protocol versioning). For more details on the distinction between the protocol and the rest of the Tezos node software, see Tezos Software Architecture.
Although a node is able to compile and upgrade to a new protocol on the fly, each release contains several embedded protocol versions. Consequently, Octez releases are created not only when new features are added or bugs are fixed, but also when new protocols are proposed or adopted.
Starting with version 7.0, releases are named using a
<major>.<minor> numbering scheme. There are also release candidates
The major version number is incremented when a new release branch is created from master. Such branches thus include many new features and possibly significant breaking changes, such as improvements to the storage layer requiring a manual upgrade that can take significant time.
The minor version number is incremented when changes are backported to an existing release branch. Such versions usually include mostly bug fixes and minor improvements. But they can also include new economic protocols and/or new versions of the economic protocol environment, so that users who do not want to migrate to newer major versions yet (because of the possible breaking changes) can still run a node and a baker for these new protocols.
Release candidates are not releases per se. They are published versions of release branches that are believed to be ready but that require further testing by the community at large. After a few days or weeks, release candidates are either considered to be stable, in which case they are actually released (losing their
~rc<N>suffix), or a new release candidate is published with an increment of
N. Usually, only major releases have release candidates.
Releases are available in several forms:
in source form, from the Tezos code repository (https://gitlab.com/tezos/tezos). Tags for each release are available prefixed by
v, and there is also a
latest-releasetag, pointing to the latest stable release (i.e., excluding release candidates). Additionally, the version under development is available in the
packaged in various forms: as standalone binaries (with no dependencies), as binary or source packages, and as Docker containers.
The packaged forms are updated from the source form as follows:
automatically, at each stable release
For recent release candidates, the static binaries are available as GitLab artifacts, pointed to in the release page of the repository.
Docker containers: two kinds of images are generated, automatically:
release images: at each release, including release candidates
master images: at each merge commit (i.e. after each merge request is merged)
at each stable release
This is currently a manual process performed by Nomadic Labs.
APT and DNF binary packages:
at each stable release
The process is currently performed manually by Serokell.
For installing Tezos from these different forms of releases, see How to get Tezos.