在評估是否棄用 Bitcoin Core 中的某個功能時，有哪些考慮因素？
在評估是否適合棄用 Bitcoin Core 中的某個功能時，有哪些考慮因素？過去的棄用方法是什麼？最近這種情況有變化嗎？當棄用被認為是合適的時，今天是否有一個流程可以遵循？
所有軟體項目都在與棄用權衡作鬥爭，這些不一定特定於比特幣核心或比特幣項目（儘管比特幣核心會被認為是更保守的一面），或者實際上是整個軟體行業。
棄用一個功能有減少維護負擔、縮小程式碼庫大小、減少測試套件執行時間以及在某些情況下簡化使用者體驗的好處（例如，如果有多個功能重疊的功能，使用者可能很難理解使用哪個功能）。
棄用某個功能的缺點是它可能會損害使用者體驗，並且可能會破壞依賴該功能的下游項目。由於我們在最壞的情況下處理開源資金，這可能意味著這些下游項目的使用者會賠錢（儘管通常我們談論的是停止工作，而不是對資金安全構成任何特定風險）。當然，棄用也可能會失敗，但任何更改都會帶來實施風險，無論是添加的功能還是刪除的功能。
這些缺點可以通過在多個版本上交錯棄用（在完全棄用之前警告日誌消息）、強調未來打算棄用的發行說明和更廣泛的通信（例如郵件列表）來緩解某個特性打算棄用的情況。當然，這並不能保證使用者或下游項目會閱讀計劃的棄用，但任何項目至少應該計劃閱讀存在依賴關係的上游項目的發行說明。有了意識並有足夠的時間提前調整他們的軟體，他們應該能夠避免對使用者產生任何負面影響。它顯然需要開發人員的時間來解決棄用問題。
比特幣核心特別獨特，因為它避開了 BDFL（終生仁慈的獨裁者）治理模型（或實際上任何具有最終權威的模型），因此除了經過審查的文件之外，沒有人可以權威地說明其目前的棄用方法是什麼.
過去，各個領域（RPC 輸入、整個 RPC、配置選項等）都有大量棄用，隨著項目的成熟以及使用者和下游數量的增加，棄用的數量似乎隨著時間的推移而減少項目已經開始依賴它。但是，如果 Core 完全停止做任何棄用，這將意味著不斷增加的維護負擔、不斷擴展的程式碼庫/測試套件以及永遠無法簡化的使用者體驗。在極端情況下，這些目前的安全風險本身作為貢獻者和維護者的時間被分配給應該被棄用的事情，而不是更重要的事情。
根據具體情況，Core 似乎仍然允許在某些情況下棄用，但只有當涉及到通信要求和下游項目風險時，它們被評估為物有所值。
有一個
-deprecatedrpc=X選項可讓您暫時恢復已棄用的 RPC（對於尚未完全刪除其程式碼的 RPC），但在撰寫本文時沒有等效的配置選項。（有關 RPC 版本控制的更多詳細資訊，請參見此處。）在撰寫本文時，有一些 PRs/issues 打算棄用舊版錢包、對舊版本的 UPnP 支持、REST API等。僅僅開放並不意味著它們一定會被合併並包含在一個版本中。
RPC 結果欄位（有時是輸入參數）仍然不推薦使用，並且可能會刪除配置選項（對此進行棄用過程可能是一種改進）。為了避免不必要地破壞 API / 使用者空間，徹底刪除 RPC 似乎更為罕見，有時 RPC 被隱藏（未在 CLI 幫助中返回）但未刪除。（喬恩·阿塔克）
如果有任何使用者在考慮有效案例的情況下使用它，我們不應該刪除它或棄用它。（馬可·法爾克）
我不喜歡棄用功能，因為還有另一種方法可以實現某些目標。這會給我們的使用者帶來挫敗感和精神負擔，因此應該有令人信服的動機來棄用。（馬可·法爾克）