|
| 1 | +--- |
| 2 | +title: Software Life Cycle |
| 3 | +name: software-life-cycle |
| 4 | +id: en-software-life-cycle |
| 5 | +permalink: /en/lifecycle/ |
| 6 | +layout: page |
| 7 | +type: pages |
| 8 | +lang: en |
| 9 | +version: 2 |
| 10 | +--- |
| 11 | +{% include toc.html %} |
| 12 | + |
| 13 | +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. |
| 14 | + |
| 15 | +## Versioning |
| 16 | + |
| 17 | +Bitcoin Core releases are versioned as follows: MAJOR.MINOR, and release candidates are suffixed with rc1, rc2 etc. |
| 18 | + |
| 19 | +## Major releases |
| 20 | + |
| 21 | +We aim to make a major release every 6-7 months. |
| 22 | + |
| 23 | +These will be numbered 22.0, 23.0 etc. |
| 24 | + |
| 25 | +## Maintenance releases |
| 26 | + |
| 27 | +We will provide maintenance "minor releases" that fix bugs within the major releases. As a general rule we do not introduce major new features in a maintenance release (except for consensus rules). However, we may add minor features where necessary, and we will back-port consensus rule changes such as soft forks. |
| 28 | + |
| 29 | +Minor releases will be numbered 22.1, 22.2, 23.1, 23.2 etc. |
| 30 | + |
| 31 | +## Consensus rules |
| 32 | + |
| 33 | +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. |
| 34 | + |
| 35 | +## Maintenance period |
| 36 | + |
| 37 | +We maintain the major versions until their "Maintenance End". We generally maintain the current and previous major release. |
| 38 | +For example, if the current release is 23.0, then 22.0 is also considered maintained. |
| 39 | +Once 24.0 is released, then 22.0 would be considered at its "Maintenance End". |
| 40 | +As a major release ages, issues have to be increasingly critical to be backported to it, and an increasing amount or severity of issues is required to warrant a new minor release. |
| 41 | +Once software has reached the "Maintenance End" period it will only receive critical security fixes until the EOL date. |
| 42 | +After EOL, users must upgrade to a later version to receive security updates, even though the community may provide fixes for critical issues on a best effort basis. |
| 43 | +Generally, it is recommended to run the latest maintenance release (point release) of the current or previous major version. |
| 44 | + |
| 45 | +Please note that minor versions get bugfixes, translation updates, and soft forks. Translation on [Transifex][bitcoin-transifex-link] is only open for the last two major releases. |
| 46 | + |
| 47 | +For example, major version 22.0 was released on 2021-09-13 and we provided maintenance fixes (point releases) until 2022-11-15. |
| 48 | +Critical security issues would still be continued to be fixed until the End-Of-Life "EOL" date of 2024-04-01. |
| 49 | +However, to take advantage of bug fixes, you would have to upgrade to a later major version. |
| 50 | + |
| 51 | +## Schedule |
| 52 | + |
| 53 | +Once EOL is reached, you will need to upgrade to a newer version. |
| 54 | + |
| 55 | +| Version | Release Date | Maintenance End | End of Life | |
| 56 | +|---------|--------------|-----------------|-------------| |
| 57 | +{% include posts/maintenance-table.md %} |
| 58 | + |
| 59 | +\* _We aim to make a major release every 6-7 months_ |
| 60 | + |
| 61 | +_TBA: to be announced_ |
| 62 | + |
| 63 | +## Protocol versioning |
| 64 | + |
| 65 | +The description above only describes Bitcoin Core software releases. Many other parts of the Bitcoin system contain their own versions. A few examples: |
| 66 | + |
| 67 | +- Every **transaction** contains a version number. |
| 68 | +- The **P2P network protocol** uses version numbers to allow nodes to announce what features they support. |
| 69 | +- Bitcoin Core's **built-in wallet** has its own internal version number. |
| 70 | + |
| 71 | +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). |
| 72 | + |
| 73 | +The consensus protocol itself doesn't have a version number. |
| 74 | + |
| 75 | +## Relationship to SemVer |
| 76 | + |
| 77 | +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. |
| 78 | + |
| 79 | +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). |
| 80 | + |
| 81 | +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. |
| 82 | + |
| 83 | +[SemVer]: https://semver.org/ |
| 84 | +[bitcoin-transifex-link]: https://www.transifex.com/bitcoin/bitcoin/ |
0 commit comments