跳至主要內容

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. 引入 慣用提交訊息
  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 系列開始，並以 beta.N 的 SemVer 預發佈標籤表示，例如 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。新發佈分支
  • 錯誤修復程式進入主分支，可以回溯到發佈分支。套用修補程式，並發佈新的 beta 版本 2.0.0-beta.2。錯誤修復程式回溯到 Beta 版本
  • beta 版本被認為是普遍穩定的，並且它以非 beta 版本的形式再次發佈於 2.0.0 之下。Beta 版本到穩定版本
  • 稍後，發現了一個零時差漏洞，並且將修復程式套用到主分支。我們將修復程式回溯到 2-0-x 線，並發佈 2.0.1。安全性回溯

一些關於各種 SemVer 範圍將如何接收新發佈版本的範例

Semvers and Releases

回溯請求流程​

所有支援的發佈版本線都將接受外部提取請求，以回溯先前合併到 main 的修正程式，儘管對於某些較舊的支援版本線，這可能是基於個別情況而定。所有關於發佈版本線回溯的爭議決定將由 發佈工作組 在他們每週會議上作為議程項目來解決，該會議是在回溯 PR 提出那一週舉行。

功能標記​

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

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

語意提交​

所有提取請求都必須遵守 慣用提交 規範，可以總結如下

  • 將導致 SemVer 主要版本更新的提交必須在其主體中以 BREAKING CHANGE: 開始。
  • 會導致 SemVer 版本號次要 (minor) 版本提升的提交，必須以 feat: 開頭。
  • 會導致 SemVer 版本號修補 (patch) 版本提升的提交，必須以 fix: 開頭。

electron/electron 儲存庫也強制使用 squash 合併，因此您只需要確保您的 Pull Request 標題有正確的前綴即可。

帶版本號的 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 的錯誤修復。