Bundler 政策

本文件旨在記錄用於管理 Bundler 專案的政策和流程，並非固定或永久不變，且可能會隨著事件的發生而演變。

我們的目標

1. 對待每個人都像是有價值的人類，值得尊重和同理心。無一例外。
2. 努力賦能使用者，也就是使用 Bundler 的 Ruby 開發人員。例如，沒有所謂的使用者錯誤，只有不足的 UX 設計。
3. 努力賦能 Bundler 貢獻者，只要這不會對使用者造成傷害。例如，潛在的貢獻者應該能夠使用單一指令設定完整的開發和測試環境。
4. 努力賦能維護人員，只要這不會對貢獻者或使用者造成傷害。例如，自動化問題分類以減少維護人員的重複工作，只要有問題的使用者不會因此處於更糟的境地。

這些政策旨在作為如何應用這些目標的範例，我們了解到我們不可能涵蓋所有邊緣案例或漏洞。在任何政策與這些目標發生衝突的情況下，目標應優先。

相容性準則

Bundler 嘗試實現完美的向下相容性。這表示如果某個功能在版本 1.x 中運作，它應該會繼續在 1.y 和 1.z 中運作。該功能可能或可能不會繼續在 2.x 中運作。我們可能無法總是正確執行，而且可能會遇到迫使我們在不同類型的中斷之間進行選擇的特殊情況，但相容性對我們來說非常重要。基礎架構應該盡可能地不出人意料。

截至 2022 年 8 月，Bundler 團隊以 2.3.x 版本發布功能和錯誤修正，並且可能會特別將安全性修正回溯套用到預設搭載受支援 Ruby 的舊系列，即 Bundler 2.1（搭載 Ruby 2.7）和 Bundler 2.2（搭載 Ruby 3.0）。

截至 2022 年 8 月，Bundler 出於向下相容性的考量，支援 Ruby 和 RubyGems 版本一直回溯到 Ruby 2.3。在放棄對舊版 Ruby 的支援時，已引入多項改善措施以避免中斷任何功能，因此我們目標在 2022 年聖誕節放棄對舊版 Ruby 的支援，並從此更緊密地遵循 Ruby 核心團隊的支援政策。

這些政策並不能保證任何特定修正會被回溯套用。相反地，這是一種讓我們為我們在進行變更時必須考量的 Ruby、RubyGems 和 Bundler 版本設定上限的方式。如果不設定上限，版本數量會隨著時間呈指數成長，並迅速變得難以負荷，這會導致維護人員倦怠。我們希望避免這種情況。

發布準則

tl;dr：主版本約每年一次，次要版本針對任何已完成並有文件說明的功能，修補版本針對任何已提交的錯誤修正。

修補版本（錯誤修正）通常應盡快發布。針對單一錯誤修正公關發布修補版本完全沒問題。

次要版本（功能）可以隨時發布，只要至少有一個新功能已準備好，但並非必要。次要版本發布必須視需要更新其主版本的手冊頁面和文件網站，且每個版本都應有自己的「新增功能」區段。

主版本（重大變更）發布應每年不超過一次，且必須包含專門針對該主版本的全新文件網站區段。理想情況下，主版本發布會在 Ruby 版本於 2 月或 3 月失去支援後進行，以協助我們與核心團隊支援的 Ruby 版本保持同步。

除了停止支援舊版 Ruby 版本之外，應盡可能避免其他重大變更，但可以包含在主版本發布中。一般來說，重大變更應在變更生效前至少包含一個主版本（且經過一年）的棄用警告。

使用者體驗準則

使用 Bundler 的體驗不應有驚喜。如果使用者感到驚訝，表示我們做錯了事，我們應修正它。沒有使用者錯誤，只有 UX 設計失敗。警告應始終包含可行的說明以解決問題。錯誤應包含說明、有用的參考或其他資訊，以協助使用者嘗試除錯。

變更現有行為也會令人驚訝。如果減少使用者驚訝會導致向後不相容的變更，則該變更應在進行重大變更之前至少包含一個主版本的棄用警告。

問題準則

歡迎任何人開啟問題或針對問題發表評論。不含有用內容的問題評論（例如「我也是」）可能會被移除。

開啟問題以尋求協助最終可能會獲得協助，但如果在 Stack Overflow 上發文或在 Bundler Slack 中詢問，協助可能會更快到來。

問題將會盡快處理，這可能會花費一些時間。包含可重現問題的指令碼是協助維護人員協助您的一種好方法。如果您能為問題撰寫失敗測試，那就更棒了。

貢獻和提交請求準則

歡迎任何人 為 Bundler 貢獻。貢獻的程式碼將在與現有程式碼庫相同的授權下發布。

提交請求必須通過測試才能合併。程式碼變更也必須包含新行為的測試。壓縮提交並非必要。

每個提交請求都應說明

1. 正在解決的問題
2. 問題發生的原因
3. 公關中包含了哪些修正問題的變更，以及
4. 為什麼在可能的選項中選擇了該實作。

RFC 指南

大型變更通常會受益於更完整的撰寫、讓其他人閱讀和討論。 Bundler RFC 回應資料庫 是發生這種情況的首選位置。

維護員團隊指南

務必建立拉取請求，而不是直接推送到主要分支。盡可能從其他人取得程式碼檢閱和合併核准。

定期貢獻超過六個月（或為次要版本實作全新功能）的貢獻者有資格加入維護員團隊。除非遭到現有維護員否決，否則會要求這些貢獻者加入維護員團隊。如果他們接受，新的維護員將獲得查看維護員手冊、接受拉取請求和發布新版本的權限。

強制執行指南

首先，Bundler 的政策和對這些政策的強制執行從屬於 Bundler 的行為準則，在任何有衝突的情況下。首要優先事項是以尊重和同理心對待人類，而找出專案指南並堅持執行這些指南永遠會在之後。

在執行我們自己的政策時，我們都是盡力而為的普通人。我們可能會在某些時候無法堅持我們的政策或目標。如果你發現實際行動與這些政策和目標之間存在差異，請提出！我們希望確保我們的行動和政策一致，並且我們的政策體現我們的目標。

政策並非一成不變，如果發現政策違規符合專案目標的精神，則可能會進行修改。同樣地，違反專案目標精神的行為將被視為政策違規，並且將採取強制執行措施。我們對規則律師不感興趣，我們將在必要時採取行動，以確保每個人都感到安全和包容。

如果你願意向整個 Bundler 團隊報告問題，請發送電子郵件至 team@bundler.io。如果你不願意向整個團隊報告，無論出於何種原因，請查看 維護員團隊清單，並使用電子郵件、Twitter 或 Slack 向你選擇的單一維護員報告。任何違反政策或目標的人員預期要與團隊（以及請求者，如果他們要求）合作，以符合專案目標的方式解決問題。