| RFC-0227：Fuchsia 發布程序 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 說明 Fuchsia 的 SDK 和 OS 發布程序 |
| 問題 |
|
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2023-08-14 |
| 審查日期 (年-月-日) | 2023-10-02 |
摘要
這項 RFC 會將現有的 Fuchsia 平台發布程序正式化。
在本 RFC 中，「發布」一詞是指產生及發布各種構件的行為，供軟體供應鏈下游的開發人員 (例如元件作者或產品擁有者) 使用。這並非指將 Fuchsia 產品的更新內容提供給使用者。
提振精神
Fuchsia 的功能發布程序已運作多年。不過，雖然外部觀察員可以看到 Fuchsia 版本和里程碑版本分支，但目前尚未有 RFC 記錄及定義這項程序。
先前的 Fuchsia 版本需要與下游合作夥伴密切協調，但每個里程碑都比先前的里程碑更平凡無奇。
為延續這股趨勢，每位 Fuchsia 開發人員都必須瞭解，自己有責任防止發布版本中斷下游合作夥伴的作業。因此，這份 RFC 會將現有 Fuchsia 發布程序中，對平台貢獻者而言最重要的部分編纂成法規。
利害關係人
協助人員：davemoore@google.com
審查者：
- billstevenson@google.com，發布計畫管理主管
- abarth@google.com，相關 RFC-0002 的作者
- atyfto@google.com，共同作者兼基礎架構主管
諮詢對象：aaronwood@google.com、chaselatta@google.com、sethladd@google.com
社會化：與專家討論，確認內容準確反映當前世界現況。
需求條件
本 RFC 說明目前的發布程序。不會建議任何變更。
如上所述，這項 RFC 並未討論如何將軟體交付給使用者。這份 RFC 中所述的構件會交付給開發人員和產品負責人。他們會使用這些構件建構軟體，最終透過超出本 RFC 範圍的程序交付給使用者。
設計
Fuchsia「版本」是指在特定時間點，Fuchsia 專案輸出的一組生成構件，並以特定「版本」名稱發布。
包括：
- 整合器開發套件 (IDK)：一小組程式庫、套件和工具，用於建構及執行以 Fuchsia 為目標的程式。
- 許多 SDK 都是以 IDK 為基礎 (例如 Bazel SDK)。
- 作業系統 (OS) 二進位檔，包括核心、啟動載入程式、套件、工具，以及設定和組裝 Fuchsia 產品組合所需的其他要素。
- 其他各種構件，例如文件和 Fuchsia 相容性測試 (CTF) 建構版本。
沒有單一封存檔包含所有這些構件；不同的構件是由不同的建構工具產生，並上傳至不同的存放區。部分構件可在線上免費取得，有些則屬於機密資訊。(事實上，IDK 和 OS 二進位檔都有公開和機密變體。)
這些廣告活動的共同點是：
- 這些版本都是以單一修訂版本的 Fuchsia 來源樹狀結構 (具體來說，是 Google 內部版本的
integration.git2) 為基礎建構而成，且 - 這些檔案都會發布到各自的存放區，且發布版本相同。
發布版本
發布版本是命名發布內容的字串。
每個發布版本在 Google 內部版本的 integration.git 中都有對應的標記，該標記會不可變動地指向建構發布版本二進位檔構件的 Git 提交。
版本名稱為 M.YYYYMMDD.R.C (例如 2.20210213.2.5)，其中
M表示發布的「里程碑」。YYYYMMDD是指發布項目的歷史記錄與main分支版本不同的日期。R表示「發布」版本號碼。這個值從 0 開始，並在同一天建立多個版本時遞增。C表示「候選」版本號碼。這個值從 1 開始，並在里程碑發布分支中對先前版本進行變更時遞增。
初期測試版
系統每天會根據 Fuchsia 來源樹狀結構的最後一個已知良好修訂版本，建立幾次3「Canary」版本。具體來說，系統會在 Google 內部版本的 integration.git 中，將 Git 標記套用至該修訂版本，並觸發各種建構工具，建構及發布上述構件。Canary 版本不會有自己的發布分支，只有標記。
每個 Canary 版本僅在短時間內提供支援，直到下一個 Canary 版本發布為止。錯誤修正不會挑選到 Canary 版本。(換句話說，初期測試版本的「候選」版本號碼一律為「1」)。如果在 Canary 版中發現錯誤，系統會將該錯誤的修正程式套用至 Fuchsia 來源樹狀結構的 main 分支。受該錯誤影響的用戶端應復原至先前的版本，和/或等待後續的 Canary 版發布，其中包含修正程式。
因此，初期測試版本適合用於開發和測試，但不一定適合用於實際工作環境。在實際作業環境中，建議使用里程碑版本。
里程碑版本
每隔幾週，系統就會在 Google 內部版本和 integration.git 的公開鏡像中，從現有的「已知良好」Canary 版本，建立 里程碑發布分支的 Git 提交。源自里程碑發布分支版本的版本稱為「里程碑版本」或「穩定版」。
里程碑會依序編號，討論時通常會加上「F」前置字元 (例如「F12 發布分支」)。
FN 里程碑發布分支版本完成後，Fuchsia 來源樹狀結構中的主線開發作業會繼續在 main 分支版本上進行，朝下一個 FN+1 版本邁進，而 Canary 版本則會以 N+1 開頭，如下圖所示：
里程碑版本會與所依據的 Canary 版本共用版本號碼的 M.YYYYMMDD.R 部分，因此在從特定里程碑版本分支建構的版本之間，只有「候選」版本號碼 C 會變更。請注意，這表示從版本中不一定能立即看出該版本是初期測試版還是里程碑版本 (不過，如果值大於 C，表示該版本來自里程碑版本分支)。
與 Canary 版本不同，里程碑版本在建立後會支援一段時間。也就是說，里程碑發布分支版本建立後，仍可進行改善。每次變更里程碑發布分支版本後，系統都會發布新的里程碑版本，並使用較大的「候選」版本號碼。
一般政策規定：
- 功能是在
main上開發，而不是在里程碑發布分支版本中。 - 里程碑發布分支版本所做的變更會先出現在
main，然後再透過 Cherry-pick 移至分支版本。 - 里程碑版本分支只會進行修正錯誤的變更 (無論錯誤與品質、安全性、隱私權、法規遵循等有關)。我們不會在里程碑版本分支中導入新功能。
這些政策旨在盡量避免里程碑發布分支版本變更時引入新錯誤，因此與特定里程碑相關聯的發布版本可靠性和穩定性應會隨著時間提升。因此，我們建議下游客戶盡快採用這些新的里程碑版本。
在某些特殊情況下，我們可能需要偏離這些政策 (例如，可能需要在機密分支版本中開發安全性修正程式，以免在修正程式準備就緒前公開漏洞)。是否要在里程碑發布分支版本中納入變更，最終由發布管理員決定。
實作
這份 RFC 並未建議對 Fuchsia 發布程序進行任何變更。
回溯相容性
Fuchsia 專案保證單一版本 (無論是 Canary 版或里程碑) 中的所有構件都彼此相容。舉例來說，如果開發人員使用 SDK 版本 2.20210213.2.5 建構元件，我們保證該元件會在 OS 版本為 2.20210213.2.5 的 Fuchsia 裝置上執行。如果元件在這些情況下發現 Fuchsia 平台行為異常，就會視為錯誤。
嚴格來說，截至本文撰寫時，Fuchsia 並未正式保證任何兩個版本之間的 API 或 ABI 相容性，也沒有現有的 RFC 討論此事。不過，在實務上，以某個版本 SDK 建構的 Fuchsia 元件，經常會在以不同版本為基礎的 Fuchsia 系統上執行，而我們仍會處理在這些設定中發現的問題。
我們會在日後的 RFC 中說明並核准跨版本 API 和 ABI 相容性的條件式承諾。
說明文件
本 RFC 的大部分內容都會複製到另一個文件，因此在 RFC 獲得批准後，這些內容仍可持續演進。
缺點、替代方案和未知事項
我們目前的版本命名方式無法清楚區分 Canary 版和里程碑版本。里程碑版本看起來就像是套用大量 Cherry-pick 的 Canary 版本。
版本號碼中出現 YYYYMMDD 在軟體中相當罕見，可能會造成誤導。一般觀察者可能會認為這是建構或發布日期，較晚日期的建構版本「較新」，但這不一定適用於里程碑版本。在某些情況下，13.20230801... 這類版本可能包含 14.20230910... 沒有的修正程式。
我們可能會改用更接近語意化版本控制的版本命名架構，並以預先發布 ID 標示 Canary 版本。
同樣地，「Canary」和「Milestone」也是非標準用語。比較常見的類似字詞是「預覽」和「穩定」。
從技術上來說，這些變更並不困難，因此我們可能會在後續的 RFC 中改善這些項目。
既有技術和參考資料
- Chromium 發布版本和版本號碼。
- semver.org