詳細查看我們的版本控制策略和實現。

從 2.0.0 版開始，Electron 遵循 SemVer 規(guī)范。以下命令將安裝最新穩(wěn)定版的 Electron：

npm install --save-dev electron

yarn add --dev electron

現有項目更新到最新的穩(wěn)定版本:

npm install --save-dev electron@latest

yarn add --dev electron@latest

Versioning scheme?

下面概述了我們的 1.x 策略的幾個主要變化。每項更改都旨在滿足開發(fā)人員/維護人員和應用程序開發(fā)人員的需求和優(yōu)先級。

1. 嚴格使用 SemVer 規(guī)范

2. 引入符合 semver 的 -beta 標簽
3. 引入常規(guī)提交消息
4. 明確定義的穩(wěn)定分支
5. main分支沒有版本信息，只有穩(wěn)定分支會包含版本信息。

我們將詳細介紹 git 分支是如何工作的，npm 標記是如何工作的，開發(fā)人員應該看到什么，以及如何能夠支持更改。

SemVer?

下面是一個表格，明確地將變化的類型映射到它們對應的 SemVer 類別 (例如Major，Minor，Patch)。

有關詳細信息，請參閱 語義版本控制 2.0.0 規(guī)范。

請注意，大多數 Chromium 更新都將被認為是破壞性的?？梢韵蚝笠浦驳男迯统绦蚩赡軙惶暨x為補丁程序。

穩(wěn)定分支?

Stabilization 分支是與 main 并行運行的分支，僅接受與安全性或穩(wěn)定性相關的精心挑選的提交。這些分支永遠不會合并回主分支。

自 Electron 8 以來，穩(wěn)定分支始終為 marjar 版本，并且根據以下模板 $MAJOR-x-y 例如： 8-x-y。 在此之前，我們使用 minor 版本行，并將它們命名為 $MAJOR-$MINOR-x 例如： 2-0-x.

我們允許同時存在多個穩(wěn)定分支，每個支持的版本一個。

Electron 項目將不支持較舊的線路，但其他團隊可以擁有所有權并自行向后移植穩(wěn)定性和安全修復程序。我們不鼓勵這樣做，但是認識到它使得許多應用程序開發(fā)人員的生活更輕松。

測試版發(fā)布和 bug 修復

開發(fā)人員想知道哪個版本可以 安全 使用。 即使是簡單的功能也會使應用程序變得復雜。 同時，鎖定到一個固定的版本是很危險的，因為你忽略了自你的版本以來可能出現的安全補丁和錯誤修復。 我們的目標是在 package.json 中允許以下標準的 semver 范圍:

• 使用 ~ 2.0. 0 只接受您的 2.0.0 版本的穩(wěn)定性或安全性相關的修復程序。
• 使用 ^ 2.0. 0 可允許不破壞性的 合理穩(wěn)定 功能以及安全性和 bug 修復。

第二點重要的是使用 ^ 的應用程序仍然能夠期望合理的穩(wěn)定性水平。 為了達到這個目的，SemVer允許使用一個 pre-release 標識 來表示一個特定的版本還不夠 安全 或 穩(wěn)定。

無論你選擇什么，你將定期不得不在 package.json 中打破版本，因為突破性變更是 Chromium 的一個常態(tài)。

過程如下:

1. 所有新的主要和次要版本系列都以 beta.N 的 SemVer 預發(fā)布標簽指示的 beta 系列開始，例如2.0.0-beta.1。在第一個測試版之后，后續(xù)的測試版必須滿足以下所有條件：

   1. 更改是落后的 API 兼容 (允許廢棄)
   2. 實現我們穩(wěn)定的時間表的危險必須是低的。
2. 如果允許更改需要在釋放測試版之后進行，則使用并增加預放標簽，例如2.0.0-beta.2。
3. 如果特定的beta版本通常被認為是穩(wěn)定的，那么它將作為穩(wěn)定版本被重新發(fā)布，只改變版本信息。例如.0。 例如 2.0.0-beta.1. 在第一個穩(wěn)定之后，所有的變化都必須落后兼容的 bug 或安全修復。
4. 如果未來錯誤修復或安全補丁一旦發(fā)布穩(wěn)定，它們將被應用，并且 補丁 版本被增量 ，例如 2.0.1。

特別地，上述步驟意味著：

1. 在測試周期的第 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

圖片中的生命周期示例:

• 創(chuàng)建了一個包含最新功能集的新發(fā)布分支。它會被發(fā)布為 2.0.0-beta.1。
• 一個 bug 修復進入 master，可以向后移植到發(fā)布分支。補丁已應用，新的測試版發(fā)布為 2.0.0-beta.2。  
• 測試版被認為是 一般穩(wěn)定 的, 它在 2.0.0 下作為非 beta 版本再次被發(fā)布。
• 之后有個 0day 漏洞被發(fā)現，然后對 master 采取了修復措施。我們將修復程序反向移植到 2-0-x 行并發(fā)布 2.0.1。
  

幾個不同的 SemVer 范圍將如何接收新版本的示例:

Backport request process?

所有受支持的發(fā)布行都將接受外部拉取請求，以向后移植先前合并到主版本的修復程序，盡管對于某些較舊的受支持行，這可能視具體情況而定。所有圍繞發(fā)布線向后移植的有爭議的決定將由發(fā)布工作組作為議程項目在他們提出向后移植 PR 的那一周的每周會議上解決。

Feature flags

功能標志是 Chromium 的一種常見的做法, 在網絡開發(fā)生態(tài)系統中得到了很好的確立。 在 Electron 環(huán)境中, 功能標志或 軟分支 必須具有以下屬性:

• 是在運行時或生成時啟用/禁用的。我們不支持請求作用域功能標志的概念
• 它完全細分新的和舊的代碼路徑; 重構舊代碼以允許新功能 違反 功能標志內容
• 在合并功能后, 功能標志最終將被刪除

語義化提交

所有拉取請求都必須遵守常規(guī)提交規(guī)范，總結如下：

• 會導致 SemVer major 版本改變的提交必須以BREAKING CHANGE:開頭。
• 會導致 SemVer minor 版本改變的提交必須以 feat: 開頭。
• 會導致 SemVer patch 版本改變的提交必須以 fix: 開頭。

electron/electron 存儲庫還強制執(zhí)行 squash 合并，因此您只需要確保您的 pull request 具有正確的標題前綴。

Versioned main branch

• 主分支將始終在其 package.json 中包含下一個主要版本 X.0.0-nightly.DATE。

• 發(fā)布分支永遠不會合并回主分支。

• 發(fā)布分支 在 其package.json 中包含正確的版本.

• 一旦一個主要的發(fā)布分支被削減，main 必須被撞到下一個主要的（即 main 總是被版本化為下一個理論上的發(fā)布分支）。

Historical versioning (Electron 1.X)

小于 2.0 的 Electron 版本編號并不遵循 SemVer 規(guī)范: major 版本對應最終用戶 API 的變更, minor 版本更新對應 Chromium 的主版本更新, patch 版本更新會帶來新功能和 bug 修復。 雖然方便開發(fā)人員合并功能，但卻為面向客戶端應用程序的開發(fā)人員帶來了麻煩。Slack、Teams、Skype、VS Code 和 GitHub Desktop 等主要應用程序的 QA 測試周期可能很長，穩(wěn)定性是非常需要的結果。嘗試吸收錯誤修復時，采用新功能的風險很高。

以下是 1.x 策略的一個例子：

使用 1.8.1開發(fā)的應用程序無法吸收 1.8.2 的功能，或者通過反向移植修復和維護新的發(fā)行版，無法采用 1.8.3錯誤修復。