软件生命周期
概述
本文档描述了比特币核心项目发布的比特币核心软件包的生命周期。它符合商业软件的标准维护策略。
版本控制
比特币核心版本号为：MAJOR.MINOR，发布候选版本后缀为 rc1、rc2 等。
主要版本
我们的目标是每 6-7 个月发布一个主要版本。
这些版本将编号为 22.0、23.0 等。
维护版本
我们将提供维护“次要版本”，用于修复主要版本中的错误。一般情况下，我们不会在维护版本中引入主要的新功能（共识规则除外）。但是，我们可能会在必要时添加次要功能，并且我们会将共识规则更改（例如软分叉）回溯到之前的版本。
次要版本将编号为 22.1、22.2、23.1、23.2 等。
共识规则
更改共识规则的提案总是先在维护版本（例如 22.2、23.1 等）中发布。由于与主要版本相比，其更改集更小，因此企业用户可以更容易地评估和测试该提案。它还允许遵循更保守升级路径的用户更及时地采用共识规则更改。
维护期
我们维护主要版本直到其“维护结束”。我们通常维护当前和之前的两个主要版本。例如，如果当前版本是 23.0，则 22.0 也被认为是维护版本。一旦 24.0 发布，则 22.0 将被视为已“维护结束”。随着主要版本的老化，要回溯到该版本的错误必须越来越关键，并且需要越来越多的错误数量或严重程度来证明新次要版本的发布是合理的。一旦软件进入“维护结束”阶段，它只会在“生命周期结束”（EOL）日期之前接收关键安全修复。在 EOL 之后，用户必须升级到更高版本才能接收安全更新，即使社区可能会尽力为关键问题提供修复。一般建议运行当前或之前主要版本的最新维护版本（点版本）。
请注意，次要版本会进行错误修复、翻译更新和软分叉。只有最近两个主要版本的翻译才允许在 Transifex 上进行。
例如，主要版本 22.0 于 2021 年 9 月 13 日发布，我们提供了维护修复（点版本）直到 2022 年 12 月 14 日。关键安全问题将继续得到修复，直到 2023 年 4 月 1 日的 EOL 日期。但是，要利用错误修复，您必须升级到更高版本的 major 版本。
时间表
一旦 EOL 到达，您将需要升级到更高版本。
| 版本 | 发布日期 | 维护结束 | 生命周期结束 |
|---|---|---|---|
| 28.x | 待定* | v30.0 发布后 | v31.0 发布后 |
| 27.x | 2024-04-16 | v29.0 发布后 | v30.0 发布后 |
| 26.x | 2023-12-06 | v28.0 发布后 | v29.0 发布后 |
| 25.x | 2023-05-18 | 2024-04-16 | v28.0 发布后 |
| 24.x | 2022-11-24 | 2023-12-12 | 2024-04-02 |
| 23.x | 2022-04-25 | 2023-05-18 | 2023-12-01 |
| 22.x | 2021-09-13 | 2022-12-14 | 2023-04-01 |
| 0.21.x | 2021-01-15 | 2022-04-25 | 2022-10-01 |
| 0.20.x | 2020-06-03 | 2021-09-13 | 2022-02-01 |
| 0.19.x | 2019-11-24 | 2021-01-15 | 2021-08-01 |
| 0.18.x | 2019-05-02 | 2020-06-03 | 2021-02-01 |
| 0.17.x | 2018-10-03 | 2019-11-24 | 2020-08-01 |
| 0.16.x | 2018-02-26 | 2019-05-02 | 2020-02-01 |
| 0.15.x | 2017-09-15 | 2018-10-03 | 2019-08-01 |
| 0.14.x | 2017-03-08 | 2018-02-26 | 2019-02-01 |
| 0.13.x | 2016-08-23 | 2017-09-15 | 2018-08-01 |
| 0.12.x | 2016-02-23 | 2017-03-31 | 2018-02-28 |
| 0.11.x | 2015-07-12 | 2016-08-23 | 2017-08-01 |
| 0.10.x | 2015-02-16 | 2016-02-29 | 2017-02-28 |
| 0.9.x | 2014-03-19 | 2015-06-16 | 2016-02-28 |
| 0.8.x | 2013-02-19 | 2014-03-19 | 2015-12-31 |
* 我们的目标是每 6-7 个月发布一个主要版本
待定：待定
协议版本控制
以上描述仅描述了比特币核心软件的发布。比特币系统的许多其他部分包含自己的版本。以下是一些例子
- 每个 交易 都包含一个版本号。
- P2P 网络协议 使用版本号来允许节点宣布其支持的功能。
- 比特币核心的 内置钱包 有自己的内部版本号。
这些版本号有意与比特币核心的版本号脱钩，因为比特币核心项目要么无法直接控制它们（例如块和交易），要么试图保持与其他项目的兼容性（例如网络协议），要么允许在某些版本中不会进行重大更改（例如内置钱包）。
共识协议本身没有版本号。
与 SemVer 的关系
比特币核心软件版本控制不遵循 SemVer 可选版本控制标准，但其发布版本控制在表面上类似。SemVer 旨在用于普通软件库，个人可以选择以自己的速度升级库，甚至如果他们不喜欢更改，也可以停留在旧版本上。
比特币的某些部分，最显着的是共识规则，并不以这种方式运作。为了使新的共识规则生效，它必须由一定数量的矿工、完整节点或两者强制执行；一旦生效，不知道新规则的软件可能会生成或接受无效的交易（尽管升级旨在防止这种情况发生，尽可能地）。
因此，比特币核心在共识规则和其他需要网络范围采用的更新方面偏离了 SemVer。比特币核心将这些更改作为维护版本（x.y）而不是主要版本（x.0）发布；这最大限度地减少了补丁的大小，以便尽可能多的人能够轻松地检查、测试和部署它。它还使得将相同的补丁回溯到多个先前的主要版本成为可能，从而进一步增加了可以轻松升级的用户数量，尽管并不总是志愿者足够多来管理它。