製作 RubyGems 發布的執行手冊。
RubyGems 的發布程序比大多數寶石都複雜。RubyGems 更新會在 包裝寶石 中發布,gem update --system
指令會下載該包裝寶石,然後執行 setup.rb
。
RubyGems 在其版本編號中遵循 語意化版本。
注意:在下方列出的文件中,*目前的*次要版本號碼為 2.7,*下一個*次要版本號碼為 2.8
不論版本為何,所有發布都必須更新 History.txt
和 lib/rubygems.rb
檔案。第一個穩定次要版本 (2.7.0
) 的變更日誌是該次要版本的所有前置預發布版本 (2.7.pre.1
、1.12.pre.2
等) 的總和。第一個穩定次要版本的變更日誌會留空,除非自上次預發布/候選版本以來有包含修正。
工作流程
一般來說,master
會接受下列的 PR
- 下一個次要版本 (2.8) 的功能合併
- 目前次要版本 (2.7) 的修補程式合併
重大版本
RubyGems 非常重視相容性。因此,會中斷相容性的變更應(只要有可能)包含相容於舊版本的功能版本,並對所有將變更的選項和行為發出警告。
我們非常努力地只在 RubyGems 的主要版本增加時發布重大變更。
精選
修補程式版本是透過從 master
精選錯誤修正來建立的。
當我們精選時,我們會使用下列指令精選合併提交
$ git cherry-pick -m 1 MERGE_COMMIT_SHAS
./util/patch_with_prs.rb
工具程式會自動處理精選,並在下方進一步說明。
歷程
RubyGems 在 History.txt
檔案中維護每個版本中變更的清單。在發布之前,會使用 ./util/update_changelog.rb
工具程式立即加入項目。通常,發布中包含的每個 PR 都會取得一個項目。
發布
次要版本
將寶石版本推送到 RubyGems.org 就像 rake release
一樣簡單,發布 RubyGems 的新版本包括許多溝通:團隊共識、git 分支、變更日誌撰寫、文件網站更新和部落格文章。
頭昏眼花嗎?我們也是。
以下是發布新次要版本的檢查清單
- 與核心團隊確認,確保在出貨功能版本方面達成共識。一般來說,這應該總是沒問題的,因為功能絕不會中斷相容性
- 從 master 建立新的穩定分支(請參閱下方的分支)
- 將
lib/rubygems.rb
中的VERSION
常數更新為新版本號碼 - 更新
History.txt
以納入版本中所有變更 - 執行
rake release
、發推文、寫部落格,讓大家知道預先發布!
在這個階段,您就是版本管理員!為自己倒幾杯好喝的飲料,考慮去熱帶地區度假。
小心,次要版本系列中的第一個版本發布後的前幾天通常會產生許多錯誤報告。這是正常的,並不表示您作為版本管理員做錯了任何事。
分支
下一個版本的次要版本從 master 的目前狀態開始建立新的版本分支:2.7
。
一旦從 master
切割出穩定的分支後,該次要版本系列 (2.7) 的變更將僅透過修補版本有目的地進行。也就是說,預設情況下對 master
的變更不會進入任何 2.7
版本,而 master
上的開發將鎖定下一個次要版本或主要版本。
修補版本(錯誤修正!)
發布新的錯誤修正版本非常簡單。增加 lib/rubygems.rb
和 History.txt
中的微小版本號碼,並針對修正的每個錯誤新增一個項目符號。然後從 2.7
(穩定)分支執行 rake release
,並為自己倒一杯好喝的飲料!
包含目前次要版本修補版本回歸修正的 PR 會合併到 master。這些提交會從 master 選取到次要分支 (2.7
)。
有一個 ./util/patch_with_prs.rb
工具程式可自動建立修補版本。它只接受一個選項,即要建立的精確修補版本(例如 --version=2.7.8
),而所有其他引數都是要包含在修補版本中的 PR 號碼。該工具程式會簽出適當的穩定分支 (2.7
),然後將這些變更(僅這些變更)選取到穩定分支。然後,該工作會提升版本檔案中的版本,提示您更新 History.txt
,接著會提交這些變更並執行 rake release
!