軟體生命週期
概覽
本文件描述了由 Bitcoin Core 專案發布的 Bitcoin Core 軟體套件的生命週期。這符合商業軟體的標準維護政策。
版本編號
Bitcoin Core 發布版本按以下方式編號：主版本號.次版本號（MAJOR.MINOR），候選版本則加上 rc1、rc2 等後綴。
主要版本
我們的目標是每 6-7 個月發布一個主要版本。
這些版本將編號為 22.0、23.0 等。
維護版本
我們將提供維護「次要版本」來修復主要版本中的錯誤。一般來說，我們不會在維護版本中引入主要的新功能（共識規則除外）。但是，在必要時我們可能會新增次要功能，並且我們會向後移植共識規則變更，例如軟分叉。
次要版本將編號為 22.1、22.2、23.1、23.2 等。
共識規則
變更共識規則的提案總是首先在維護版本（例如 22.2、23.1 等）中發布。這使企業使用者更容易評估和測試該提案，因為與主要版本相比，其變更集較小。這也允許遵循更保守升級路徑的使用者能夠更及時地採用共識規則變更。
維護期
我們維護主要版本直到其「維護終止」（Maintenance End）日期。我們通常維護當前和前一個主要版本。 例如，如果當前版本是 23.0，則 22.0 也被視為正在維護中。 一旦發布 24.0，則 22.0 將被視為「維護終止」。 隨著主要版本逐漸老化，只有越來越重大的問題才會被向後移植，並且需要越來越多或越來越嚴重的問題才能保證發布新的次要版本。 一旦軟體到達「維護終止」期間，它將僅接收重大安全修復，直到生命週期終止（End-of-Life, EOL）日期。 在 EOL 之後，使用者必須升級到更新版本才能接收安全更新，儘管社群可能會盡力為重大問題提供修復。 通常建議執行當前或前一個主要版本的最新維護版本（點版本）。
請注意，次要版本會獲得錯誤修復、翻譯更新和軟分叉。Transifex 上的翻譯僅對最後兩個主要版本開放。
例如，主要版本 22.0 於 2021-09-13 發布，我們提供維護修復（點版本）直到 2022-12-14。 重大安全問題仍將繼續修復，直到 2023-04-01 的 EOL 日期。 但是，要利用錯誤修復，您必須升級到更新的主要版本。
時程表
一旦達到 EOL，您將需要升級到更新的版本。
| 版本 | 發布日期 | 維護終止 | 生命週期終止 |
|---|---|---|---|
| 32.x | TBA* | after v35.0 | |
| 31.x | 2026-04-19 | after v34.0 | |
| 30.x | 2025-10-10 | after v33.0 | |
| 29.x | 2025-04-14 | after v32.0 | |
| 28.x | 2024-10-02 | 2026-04-19 | |
| 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 |
* 我們的目標是每 6-7 個月發布一個主要版本
TBA：待公告
協議版本編號
上述描述僅描述 Bitcoin Core 軟體版本。Bitcoin 系統的許多其他部分包含自己的版本號。幾個範例：
- 每個交易都包含一個版本號。
- P2P 網路協議使用版本號來讓節點宣告它們支援的功能。
- Bitcoin Core 的內建錢包有自己的內部版本號。
這些版本號刻意與 Bitcoin Core 的版本號分離，因為 Bitcoin Core 專案要麼沒有直接控制它們（如區塊和交易的情況），要麼試圖與其他專案保持相容性（如網路協議的情況），或者允許在某些版本中可能不會進行重大變更（如內建錢包有時的情況）。
共識協議本身沒有版本號。
與 SemVer 的關係
Bitcoin Core 軟體版本編號不遵循 SemVer 可選版本編號標準，但其發布版本編號在表面上是相似的。SemVer 是為一般軟體函式庫設計的，個人可以選擇按照自己的步調升級函式庫，甚至如果不喜歡變更，可以停留在較舊的版本上。
Bitcoin 的某些部分，最顯著的是共識規則，不是這樣運作的。為了使新的共識規則生效，它必須由一定數量的礦工、全節點或兩者來執行；一旦它生效，不知道新規則的軟體可能會產生或接受無效的交易（儘管升級的設計是為了盡可能防止這種情況發生）。
因此，對於共識規則的變更以及其他需要或希望全網路採用的更新，Bitcoin Core 偏離了 SemVer。Bitcoin Core 將這些變更作為維護版本（x.y）而不是主要版本（x.0）發布；這最小化了修補程式的大小，以便讓盡可能多的人更容易檢查、測試和部署它。這也使得可以將相同的修補程式向後移植到多個先前的主要版本，進一步增加可以輕鬆升級的使用者數量，儘管並不總是有足夠的志願者來管理這個過程。