跳到主要內容

Electron 版本控制

詳細了解我們的版本控制政策與實作方式。

從 2.0.0 版本開始，Electron 遵循 SemVer 規範。以下指令將安裝 Electron 最新的穩定版本

npm install --save-dev electron

若要更新現有專案以使用最新的穩定版本

npm install --save-dev electron@latest

版本控制方案​

相較於我們的 1.x 策略，以下概述了幾項重大變更。每項變更均旨在滿足開發人員/維護人員和應用程式開發人員的需求與優先事項。

  1. 嚴格使用 SemVer 規範
  2. 導入符合 semver 規範的 -beta 標籤
  3. 導入 conventional commit messages
  4. 定義完善的穩定分支
  5. main 分支為無版本；只有穩定分支包含版本資訊

我們將詳細說明 git 分支如何運作、npm 標記如何運作、開發人員應預期看到什麼，以及如何回溯移植變更。

SemVer​

以下表格明確地將變更類型對應到其對應的 SemVer 類別（例如，主要、次要、修補程式）。

主要版本增量次要版本增量修補程式版本增量
Electron 破壞性 API 變更Electron 非破壞性 API 變更Electron 錯誤修正
Node.js 主要版本更新Node.js 次要版本更新Node.js 修補程式版本更新
Chromium 版本更新與修正相關的 chromium 修補程式

如需更多資訊，請參閱 語意化版本 2.0.0 規範。

請注意，大多數 Chromium 更新將被視為破壞性變更。可以回溯移植的修正程式可能會以修補程式的形式進行挑選。

穩定分支​

穩定分支是與 main 平行運行的分支，僅接受與安全性或穩定性相關的挑選提交。這些分支永遠不會合併回 main。

Stabilization Branches

自 Electron 8 起，穩定分支始終為主要版本線，並根據以下範本 $MAJOR-x-y 命名，例如 8-x-y。在此之前，我們使用次要版本線，並將其命名為 $MAJOR-$MINOR-x，例如 2-0-x。

我們允許同時存在多個穩定分支，每個支援的版本各有一個。如需更多關於哪些版本受到支援的詳細資訊，請參閱我們的 Electron 發行版本 文件。

Multiple Stability Branches

較舊的版本線將不再受到 Electron 專案的支援，但其他群組可以取得所有權並自行回溯移植穩定性和安全性修正程式。我們不鼓勵這樣做，但認知到這能讓許多應用程式開發人員的生活更輕鬆。

Beta 版本與錯誤修正​

開發人員想知道哪些版本是安全可用的。即使看似無害的功能也可能在複雜的應用程式中引入回歸。同時，鎖定固定版本是危險的，因為您會忽略自您的版本以來可能發布的安全性修補程式和錯誤修正。我們的目標是允許在 package.json 中使用以下標準 semver 範圍

  • 使用 ~2.0.0 僅允許將與穩定性或安全性相關的修正程式套用至您的 2.0.0 版本。
  • 使用 ^2.0.0 允許非破壞性合理穩定的功能開發，以及安全性與錯誤修正。

第二點重要的是，使用 ^ 的應用程式仍然應該能夠預期合理的穩定性水平。為了實現這一點，SemVer 允許使用預發行識別符號來指示特定版本尚未安全或穩定。

無論您選擇什麼，您都必須定期在您的 package.json 中增加版本號，因為破壞性變更是 Chromium 生命週期中的事實。

流程如下

  1. 所有新的主要和次要版本線都以 beta 系列開始，該系列由 SemVer 預發行標籤 beta.N 指示，例如 2.0.0-beta.1。在第一個 beta 版本之後，後續的 beta 版本必須滿足以下所有條件
    1. 變更向後 API 相容（允許棄用）
    2. 滿足我們的穩定性時程表的風險必須很低。
  2. 如果一旦發布 beta 版本後需要進行允許的變更，則會套用這些變更並增加預發行標籤，例如 2.0.0-beta.2。
  3. 如果特定 beta 版本被普遍認為是穩定的，則它將以穩定版本重新發布，僅變更版本資訊。例如 2.0.0。在第一個穩定版本之後，所有變更都必須是向後相容的錯誤或安全性修正。
  4. 如果一旦發布穩定版本後需要進行未來的錯誤修正或安全性修補程式，則會套用這些變更並增加修補程式版本，例如 2.0.1。

具體而言，以上表示

  1. 在 beta 週期第 3 週之前，允許非破壞性 API 變更，即使這些變更可能導致中等程度的副作用也沒關係。
  2. 在 beta 週期的多數時間點，允許不以其他方式更改現有程式碼路徑的功能標記變更，是可以接受的。使用者可以在他們的應用程式中明確啟用這些標記。
  3. 在 beta 週期第 3 週之後，未經非常好的理由，不允許任何種類的功能 👎。

對於每個主要和次要版本提升，您應該預期會看到如下所示的內容

2.0.0-beta.1
2.0.0-beta.2
2.0.0-beta.3
2.0.0
2.0.1
2.0.2

圖片範例生命週期

  • 建立一個新的發行分支，其中包含最新的功能集。它以 2.0.0-beta.1 發布。New Release Branch
  • 一個錯誤修正進入主分支，可以回溯移植到發行分支。修補程式已套用，並且以 2.0.0-beta.2 發布新的 beta 版本。Bugfix Backport to Beta
  • 該 beta 版本被認為是普遍穩定的，並且再次以非 beta 版本 2.0.0 發布。Beta to Stable
  • 稍後，一個零時差漏洞被揭露，並且修正程式已套用至主分支。我們將修正程式回溯移植到 2-0-x 版本線並發布 2.0.1。Security Backports

各種 SemVer 範圍將如何選取新發行版本的幾個範例

Semvers and Releases

回溯移植請求流程​

所有受支援的發行版本線都將接受外部提取請求，以回溯移植先前合併到 main 的修正程式，儘管對於某些較舊的受支援版本線，這可能需要視情況而定。關於發行版本線回溯移植的所有有爭議的決策，將由 發行工作組 在他們的回溯移植 PR 提出的當週每週會議議程項目中解決。

功能標記​

功能標記是 Chromium 中的常見實務，並且在 Web 開發生態系統中已建立完善。在 Electron 的上下文中，功能標記或軟分支必須具有以下屬性

  • 它在運行時或建置時啟用/停用；我們不支援請求範圍功能標記的概念
  • 它完全區隔了新舊程式碼路徑；重構舊程式碼以支援新功能違反了功能標記合約
  • 功能標記在功能發布後最終會被移除

語意化提交​

所有提取請求都必須遵守 Conventional Commits 規範，該規範可總結如下

  • 會導致 SemVer 主要版本提升的提交，其主體必須以 BREAKING CHANGE: 開頭。
  • 會導致 SemVer 次要版本提升的提交，必須以 feat: 開頭。
  • 會導致 SemVer 修補程式版本提升的提交，必須以 fix: 開頭。

electron/electron 儲存庫也強制執行 squash 合併，因此您只需要確保您的提取請求具有正確的標題前綴即可。

版本化的 main 分支​

  • main 分支在其 package.json 中將始終包含下一個主要版本 X.0.0-nightly.DATE。
  • 發行分支永遠不會合併回 main。
  • 發行分支確實在其 package.json 中包含正確的版本。
  • 一旦主要版本的發行分支被切出，main 必須提升到下一個主要版本（即 main 始終被版本化為下一個理論發行分支）。

歷史版本控制 (Electron 1.X)​

Electron 版本 < 2.0 不符合 SemVer 規範：主要版本對應於終端使用者 API 變更，次要版本對應於 Chromium 主要版本，而修補程式版本對應於新功能和錯誤修正。雖然這對於合併功能的開發人員來說很方便，但它為面向客戶端應用程式的開發人員帶來了問題。Slack、Teams、Skype、VS Code 和 GitHub Desktop 等主要應用程式的 QA 測試週期可能很長，而穩定性是高度期望的結果。在嘗試吸收錯誤修正的同時採用新功能存在很高的風險。

以下是 1.x 策略的範例

1.x Versioning

使用 1.8.1 開發的應用程式無法在不吸收 1.8.2 功能的情況下取得 1.8.3 錯誤修正，或者透過回溯移植修正程式並維護新的發行版本線。