Software Life Cycle
Overview
This document describes the life-cycle of the Bitcoin Core software package released by the Bitcoin Core project. It is in line with standard maintenance policy across commercial software.
Versioning
Bitcoin Core releases are versioned as follows: MAJOR.MINOR, and release candidates are suffixed with rc1, rc2 etc.
We aim to make a major release every 6 months. These will be numbered 29.0, 30.0 etc.
We will provide minor (“maintenance”) releases that fix bugs (security and otherwise) for each major release. These will be numbered 29.3, 30.1, etc. We will not introduce major new features in maintenance releases (besides consensus rules change, see below).
Consensus rules
Proposals to change consensus rules are always shipped first in maintenance versions such as 22.2, 23.1 etc. This makes it easier for enterprise users to assess and test the proposal because of its smaller changeset compared to a major release. It also allows users who follow a more conservative upgrade path to adopt consensus rule changes in a more timely manner.
Maintenance period
We always maintain the latest three major versions. When a new major version is released, the oldest one falls out of the maintenance window and becomes “End of Life”. For example, if the last major release is 30.0, then 29.x and 28.x are also considered maintained. Once 31.0 is released, 28.x becomes “End of Life”. The threshold for backporting a change to an older major version increases as it ages.
Major versions that are “End of Life” do not generally receive security fixes. For more about our policy on security fixes, see our security advisories page. We recommend running the latest maintenance release of the most recent major version you are able to upgrade to.
Schedule
Once EOL is reached, you will need to upgrade to a newer version.
| Version | Release Date | End of Life |
|---|---|---|
| 31.x | TBA* | after v34.0 |
| 30.x | 2025-10-10 | after v33.0 |
| 29.x | 2025-04-14 | after v32.0 |
| 28.x | 2024-10-02 | after v31.0 |
| 27.x | 2024-04-16 | 2025-10-10 |
| 26.x | 2023-12-06 | 2025-04-14 |
| 25.x | 2023-05-18 | 2024-10-02 |
| 24.x | 2022-11-24 | 2024-04-02 |
| 23.x | 2022-04-25 | 2023-12-01 |
| 22.x | 2021-09-13 | 2023-04-01 |
| 0.21.x | 2021-01-15 | 2022-10-01 |
| 0.20.x | 2020-06-03 | 2022-02-01 |
| 0.19.x | 2019-11-24 | 2021-08-01 |
| 0.18.x | 2019-05-02 | 2021-02-01 |
| 0.17.x | 2018-10-03 | 2020-08-01 |
| 0.16.x | 2018-02-26 | 2020-02-01 |
| 0.15.x | 2017-09-15 | 2019-08-01 |
| 0.14.x | 2017-03-08 | 2019-02-01 |
| 0.13.x | 2016-08-23 | 2018-08-01 |
| 0.12.x | 2016-02-23 | 2018-02-28 |
| 0.11.x | 2015-07-12 | 2017-08-01 |
| 0.10.x | 2015-02-16 | 2017-02-28 |
| 0.9.x | 2014-03-19 | 2016-02-28 |
| 0.8.x | 2013-02-19 | 2015-12-31 |
* We aim to make a major release every 6-7 months
TBA: to be announced
Protocol versioning
The description above only describes Bitcoin Core software releases. Many other parts of the Bitcoin system contain their own versions. A few examples:
- Every transaction contains a version number.
- The P2P network protocol uses version numbers to allow nodes to announce what features they support.
- Bitcoin Core’s built-in wallet has its own internal version number.
These version numbers are deliberately decoupled from Bitcoin Core’s version number as the Bitcoin Core project either has no direct control over them (as is the case with blocks and transactions), or tries to maintain compatibility with other projects (as is the case with the network protocol), or allows for the possibility that no major changes will be made in some releases (as is sometimes the case with the built-in wallet).
The consensus protocol itself doesn’t have a version number.
Relationship to SemVer
Bitcoin Core software versioning does not follow the SemVer optional versioning standard, but its release versioning is superficially similar. SemVer was designed for use in normal software libraries where individuals can choose to upgrade the library at their own pace, or even stay behind on an older release if they don’t like the changes.
Parts of Bitcoin, most notably the consensus rules, don’t work that way. In order for a new consensus rule to go into effect, it must be enforced by some number of miners, full nodes, or both; and once it has gone into effect, software that doesn’t know about the new rule may generate or accept invalid transactions (although upgrades are designed to prevent this from happening when possible).
For this reason, Bitcoin Core deviates from SemVer for changes to consensus rules and other updates where network-wide adoption is necessary or desirable. Bitcoin Core releases these changes as maintenance releases (x.y) instead of as major releases (x.0); this minimizes the size of the patch in order to make it easy for as many people as possible to inspect it, test it, and deploy it. It also makes it possible to backport the same patch to multiple previous major releases, further increasing the number of users who can easily upgrade, although there are not always enough volunteers to manage this.