發布管道

Tuist 伺服器與 Kura 快取伺服器透過三個 GHCR 映像檔管道發布，各自提供不同的穩定性保證。建議安裝 stable 頻道，每週更新一次：它不會在每次功能合併至 main 時就推進，因此升級不再意味著吸收一批無關的變更。早期採用者仍可在 canary 上執行每次提交的建置，而 release candidate 頻道則讓你在版本線成為穩定版之前先行試用。

伺服器與 Kura 都搭乘相同的每週列車，並與 Tuist CLI 的發布時程同步推進。

各管道#

管道	版本格式	頻率	會推進 `:latest` 嗎？
Canary	`X.Y.0-canary.N`（例如 `1.351.0-canary.5`）	每次提交至 `main`	否，需明確選擇
Release candidate	`X.Y.0-rc.N`（例如 `1.351.0-rc.1`）	每週一從 `main` 切出，試用約 1 週	否，需明確選擇
Stable	`X.Y.Z`（例如 `1.350.2`、`1.351.0`）	經過乾淨試用後，於每週一推進	是

Canary 與 release-candidate 建置會以 GitHub 預發布形式發布。任何在解析 :latest 時排除預發布版本的工具都會略過它們，因此只有在你明確指定時才會使用其中任一版本。

每次提交至 main 都會發布一個 canary 映像檔。Canary 始終代表 下一個尚未發布的次要版本：一旦為發布切出版本線，main 就會推進到下一個次要版本（例如從 1.350.0-canary.42 到 1.351.0-canary.1）。若你需要一個鏡像生產環境的暫存環境，以便最早收到回歸問題的訊號，或想在修復進入穩定版之前驗證你回報的修正是否符合預期，Canary 就是合適的管道。

plaintext

ghcr.io/tuist/tuist:1.351.0-canary.5
ghcr.io/tuist/kura:0.55.0-canary.5

Release candidate#

當某個次要版本準備好交付時，其版本線會被凍結到受保護的 releases/server-<major>.<minor>.x（或 releases/kura-<major>.<minor>.x）分支，並以 X.Y.0-rc.1 的形式發布。該版本線處於功能凍結狀態；只會挑選關鍵修復與回歸修補，且每個被接受的修復都會迭代 release candidate 版本（-rc.2、-rc.3 等）。在試用期順利結束後，該版本線將於隔週一推進為穩定版。

plaintext

ghcr.io/tuist/tuist:1.351.0-rc.1
ghcr.io/tuist/kura:0.55.0-rc.1

Stable#

Stable 是建議使用的管道，也是所有文件指向的版本。只有在 release candidate 經過乾淨試用後，才會發布穩定版的次要版本（X.Y.0），而且當新功能合併至 main 時，它不會推進。穩定版本線上的修補版本（X.Y.1、X.Y.2 等）僅包含回溯移植的修復，絕不包含新功能。:latest 只會在穩定版推進時移動。

plaintext

ghcr.io/tuist/tuist:1.351.0
ghcr.io/tuist/kura:0.55.0
ghcr.io/tuist/tuist:latest
ghcr.io/tuist/kura:latest

週一列車#

每週一 UTC 06:00，三個元件的發布列車會同步觸發：

06:00 UTC — 執行推進作業。每個作業會推進最新且尚未成為穩定版的 release-candidate 版本線（通常是前一個週一切出的版本線）；若沒有候選版本，則不執行任何動作。
每次推進完成後 — release-candidate 作業會從 main 切出下一個版本線，因此剛切出的版本線不會在同一輪中就被推進。

若推進失敗，切出動作會被擱置：系統只會挑選高於最新穩定版的最高 release-candidate 版本線，因此在失敗之上再切出新版本線會讓未交付的版本線孤立。下個週一會自動重試被擱置的版本線。

固定管道#

在你的部署清單、Helm 值或 Docker Compose 檔案中固定你想要的特定標籤。以下以 Helm chart 為例：

yaml

server:
  image:
    repository: ghcr.io/tuist/tuist
    tag: "1.350.2"          # Pinned to a stable patch
    # tag: "1.351.0-rc.1"   # Or opt into a release candidate to soak it
    # tag: "1.351.0-canary.5" # Or opt into a specific canary build

kuraRuntime:
  image:
    repository: ghcr.io/tuist/kura
    tag: "0.54.0"           # Same three channels apply to Kura

:latest 在 ghcr.io/tuist/tuist 與 ghcr.io/tuist/kura 上都會追蹤最新的穩定版，且僅在週一推進時移動。固定 :latest 可讓你享有每週穩定版的節奏，無需手動更新標籤；固定特定版本則可讓你完全掌控升級時機。

建議策略#

這些管道的存在，是為了讓你將「取得最新修復」與「取得最新功能」解耦。一個安全且低維護成本的預設做法是：

將生產環境固定在穩定的次要版本線，例如 ghcr.io/tuist/tuist:1.351。該版本線只會接收回溯移植的修復，絕不包含新功能，因此日常升級風險較低。當你準備採用下一個次要版本時，再更新固定的版本。
在 canary 或特定的 release-candidate 標籤上執行暫存環境。 暫存環境能攔截原本會影響使用者的回歸問題，而且暫存環境越接近 main，你就能越早發現問題。在目前的 release-candidate 版本線上執行暫存環境是個良好的折衷方案：它會完整試用即將在下個週一成為穩定版的相同內容。
查看伺服器變更紀錄以了解實際交付的內容。 每次穩定版推進都會在此公告，並列出納入的拉取請求。

如果你希望新功能在成為穩定版後自動部署至生產環境，請將生產環境保持在 :latest。請注意，該標籤會在每週一上午推進，因此請據此安排你的部署時段。

回溯移植#

任何時候都會積極維護兩條穩定的伺服器（與 Kura）版本線：目前版本線會透過回溯移植的拉取請求接收回歸修復與安全性修復，而前一條版本線僅接收關鍵與安全性修復。較舊的版本線不會進行回溯移植；請升級至受維護的版本線以取得修復。當新版本線被推進為穩定版時，原本的「目前」版本線會變成「前一條」，而原本的「前一條」版本線則會停止接收回溯移植。

回溯移植會按需切出為 X.Y.(Z+1) 修補版本。它們絕不會移動 :latest。