Git Flow and Release Process

Library Version Compatibility

Spartacus 專案由一組庫組成。 為了更容易知道哪個版本的庫與另一個版本相容，庫版本在所有包之間同步。 這意味著當我們要釋出 1.5.0 版本時，我們會發布此版本下的所有庫，即使某些庫自上一版本以來沒有任何更改。 這樣做時，我們可以使用單個版本號來引用任何給定版本的整個 Spartacus 庫集。

這也意味著您可以確信，如果您安裝所有具有相同版本的軟體包，那麼一切都將正常工作。 不同版本的庫可以很好地協同工作，但我們不會測試這些配置，也不能保證正確的行為。

version support

對於版本控制，我們遵循語義版本控制，也稱為 SemVer。 除了穩定版本，Spartacus 還生產 next 和 rc 版本。

我們對版本的假設如下：

• Stable 版本是經過良好測試的 Spartacus 版本（包括社群測試），並且只會修補錯誤。這些版本在 npm 上的最新標籤下可用。

• 當 Spartacus 團隊完成該版本所有新功能的開發後，就會發佈一個 rc 版本，這意味著功能和公共 API 不會有任何重大變化。社群可以安全地開始測試 rc 版本中的功能。 rc 版本可能包含一些錯誤，這些錯誤將在穩定版本釋出之前修復。當沒有更多錯誤並且社群停止報告該版本的問題時，我們會繼續製作穩定版本。

• 當 Spartacus 團隊完成特定功能時，將釋出一個 next 版本。這允許社群立即開始測試該功能。這些 next 版本可能包含很多錯誤，功能和公共 API 可能仍會發生變化。如果您想盡快測試新功能，這是適合您的版本。下一個版本在 npm 上的 next 標籤下可用。

注意：強烈建議您不要在生產設定中使用 next 版本。這是因為從next 版本升級可能比從一個穩定版本升級到另一個要困難得多。

Support Policy

始終支援至少一個穩定或 rc 版本。

一旦版本 x.y 釋出，它將被積極維護，直到版本 x.z 的新穩定版或 rc 釋出。 屆時，版本 x.z 將成為積極維護的版本，下一個版本的工作將開始。

例如，假設我們剛剛釋出了 1.5.0-rc.0 版本。 從那時起，將積極維護 1.5.x 版本，直到我們釋出 1.6.0-rc.0。 一旦 1.6.0-rc.0 版本釋出，我們就會將主動支援切換到 1.6.x 版本。

注意：對於重要的安全問題或關鍵的錯誤修復，可能會有針對不再積極維護的版本的附加補丁。

Git Flow

Spartacus 專案中的流程圍繞前面部分中描述的版本支援構建。

develop 分支是預設分支，用於新版本開發，包括次要和主要版本。 所有功能和錯誤修復都合併到這個分支。

還有一個 maintenance 分支，它隨著新的穩定版或 rc 版本而變化，用於補丁版本。 只有錯誤修復合併到 maintenance 分支。

一旦我們釋出了 1.4.0-rc.0 版本，release/1.4.x 分支將被視為維護分支。 當我們釋出 1.5.0-rc.0 版本時，則 release/1.5.x 分支成為維護分支，依此類推。

其他分支約定：

• feature/GH-xxxx 分支用於簡單的功能和錯誤修復
• epic/epic-name 分支用於大特徵（稱為 epics）
• release/1.4.0-rc.0 分支用於特定的釋出（你可以將它們與維護分支區分開來，因為包含完整的版本號）

Flow for Epic Development

• 從 develop 分支建立一個新的 epic/epic-name分支。

• 從epic/epic-name 為epic 子任務建立分支，並將它們合併回 epic/epic-name 分支。

• 不時地使用來自 develop 分支的更改更新您的 epic/epic-name 分支（它將幫助您管理衝突）。

• 當 epic 完成時，建立一個 PR 並將 epic/epic-name 分支合併到 develop 分支。

Flow for Smaller Features

• 從 develop 分支建立一個新的 feature /GH-xxxx 分支。

• 開發您的功能。

• 完成後，建立一個 PR 並將 feature/GH-xxxx 分支合併到 develop 分支。

錯誤修復流程

以下是處理錯誤修復的步驟：

• 從開發分支建立一個新的 feature/GH-xxxx 分支。

• 修復錯誤。

• 建立 PR 並將 feature/GH-xxxx 分支合併到 develop 分支。

• 如果此修復適用於積極支援的版本，請從 maintenance 分支建立一個新的 feature/GH-xxxx-maintenance 分支。

• Cherry pick the commit with the fix from the develop branch.

• 建立 PR 並將 feature/GH-xxxx-maintenance 合併到 maintenance 分支中。

Terminology

以下是我們目前使用的可能會產生誤導的術語：

“feature freeze” 描述了我們完成了新的次要或主要版本的所有功能的那一刻（這意味著我們希望很快釋出一個 rc，但仍需要修復一些錯誤）。

“code freeze” 描述了我們停止提交程式碼的那一刻（儘管這在我們的流程中不是必需的，因為我們總是可以切斷髮布或維護分支並繼續提交）。

以下概念可用於替換這些術語：

我們可以建立一個新的維護分支併發佈一個新的 rc。 第一個 RC 可能有問題，因為 rc 版本可能包含錯誤是公認的。

我們可以建立一個新的 release 分支，而不是凍結程式碼。 我們永遠不需要阻塞主要的開發或維護分支（我們不需要用這些細節來打擾開發人員，因為我們的流程支援在這些分支上併發工作併發布另一個版本）。

term：維護分支，特性分支

maintenance 分支是需要合併到release/xxx的東西

示例：你合併了一些東西來開發，但它需要在 4.0.1 中或者也需要向後移植到另一箇舊的釋出分支，然後你需要建立一個 PR 來將它合併到 release/4.0.x 。

通常，新功能維護分支最終是 feature/GH-xxx-maintenance 並將合併到 release/xxx 而不是 develop。