版本

使用者 > 版本說明我們如何進行自動化版本發布。對於每週版本，通常不需要進行任何維護活動。

不過，我們鮮少會進行兩種版本的發布，每一種都需要手動執行。

重大版本

依據使用者 > 版本 > 重大版本的內容，我們會不定期地發布累積重大變更的重大版本。

1. 預發布準備

建立一個里程碑，其名稱為發布版本 [範例：里程碑 6.0.0]。
如果對於建議規則組態變更的議題尚未存在，請建立一個 [範例：5.0.0 的「推薦」組的變更]。
將任何預計在該版本中發生的重大變更新增到該里程碑中。
搜尋原始程式碼註解（排除 CHANGELOG.md 檔案），提及過時的程式碼和/或新主要版本的待辦事項，並在該里程碑中建立對應的議題。
- 例如，對於新主要版本 8，搜尋可能包括
  - /過時|待辦/i
  - /v8/i
  - /待辦.*v?8/i
建立議題來提升相依項的最低版本 [範例：加強功能：提升 v8 相依項的最低版本]。
在專案儲存庫中（不是個人分支）從 main 建立兩個新分支
- v${主要}
- v${主要}-金絲雀自動版本
從 v${主要}-金絲雀自動版本 發起一個公關請求到 main，修改 ci.yml 工作流程和 README.md [範例：雜務：為 v6 新增金絲雀自動版本]。
- ci.yml:
  - 在檔案開頭的 push: > branches: 下方，新增一個 - v${主要} 清單項目。
  - 新增一個 publish_canary_version_v${主要} 步驟，與 publish_canary_version 相同，但
    - 將 if 條件的分支檢查變更為：if: github.ref == 'refs/heads/v${主要}'。
    - 其發布指令應為 npx nx release publish --tag rc-v${主要} --verbose。
- README.md:
  - 新增連結到 Netlify 上的 v${主要}--typescript-eslint.netlify.app 預覽部署環境，該環境是您為該分支建立的。
- 在審查完成並且重新分歧 v${主要} 分支後，將此合併到 main 中。

1a. 共享組態變更

主要版本是我们唯一能更改我們穩定 recommended* 和 stylistic* 組態變更值的機會。在主要版本的普遍公關流程中

在 Typescript-ESLint Discord 上建立一個 v${主要} 頻道
建立一個討論串，其表格中摘要列出任何建議的規則變更 [範例：6.0.0 的組態變更]。
在 Typescript-ESLint Discord 和社群媒體上發表該討論串
一旦（1 個月）與（討論解決）中較長的期限已過，請提出問題並將對應的 PR 傳送給 v${major} 分支，以進行對應的變更 [範例：組態：套用 v6 的組態預設值變更]

1b. 自願社區測試

在進行共享組態變更工作時，請務必在願意試用的熱門社區專案上測試 beta 版。

建立固定式問題，供使用者試用新版本的 beta 版 [範例：在各種有影響力的社區存放庫上試用 v8 beta 版]
- 詢問各個社區專案是否有興趣試用新版本，例如在他們的 Discord 中或其問題追蹤器上詢問。
- 每個表示願意接收 PR 的社區專案都應該有一個。
一旦所建議的共享組態變更合併到 v${major} 分支，請向各個專案傳送包含新 beta 版本的 PR 草稿。

1c. 在社區測試後進行組態微調

在社區測試中可能會發現預設組態的其他變更。如果是這種情況的話

建立討論並說明建議的變更 [範例：組態：對 v6 組態最後一輪「最終」變更]
在之前的組態變更中發布這項新的討論，並在 typescript-eslint Discord 與社群媒體上發布。
一旦（2 週）與（討論解決）中較長的期限已過

如果可能，我們希望避免進行第二輪組態變更，這些變更應僅用於在社區測試中持續出現的回饋。

2. 合併重大變更

從 v${major} 傳送 PR 至 main [範例： v6.0.0]
將所有重大變更 PR 修改為以 v${major} 分支為目標。
- 要表示這些變更為重大變更，PR 說明的第一行必須標示為 BREAKING CHANGE:，第二行應簡短摘要變更。
- 合併時須注意，提交訊息的第一行必須包含 BREAKING CHANGE:，以供 nx release 在版本說明中辨識為中斷變更。若遺漏這項訊息，在撰寫版本文件時就必須花費更多精力在手動作業上。
撰寫並分享部落格文章，公告新的測試版 [範例：文件：部落格文章說明 v5->v6 的變更和遷移策略]
- 在 v${major} 分支中修正這篇文章，以隨時反映變更記錄。
等到所有必要的公關都被合併後
撰寫部落格文章公告新的版本 [範例：文件：v6 的版本部落格文章]]，並將文章載入 v${major} 分支中。
讓版本等待至少 1 週，以便讓早期採用者提供測試，並討論變更。
- 在 @tseslint 推特上宣傳，以獲得更多關注。
當討論告一段落，請對儲存庫暫時啟用合併設定，並將公關合併提交到 main 上方。

備註

非中斷變更可以合併到 main 或主要分支中。這些變更不需要特殊處理。

3. 版本發佈

與維護人員討論，以便準備好即時發佈。手動執行此步驟有助於確保有專人處理主要發佈可能發生的任何問題。
準備版本說明。nx release 會自動在 GitHub 上產生版本說明，但這些說明會很雜亂無序，且對使用者沒有幫助。我們必須重新整理版本說明，並將中斷變更放在最上方，以讓它們最引人注目。如果需要進行任何遷移，我們必須列出步驟，讓使用者執行起來更容易。
- 版本說明範例：v6.0.0、v5.0.0
最後，使用連結至 GitHub 發布的網址在推特上 @tseslint 發布貼文。請務必加入與發布相關之額外資訊！

臨時發布

根據使用者 > 發布 > 臨時發布，我們可能會針對嚴重回歸等罕見緊急狀況手動觸發新發布。如果發生此類情況

在任何相關問題中提及您打算發布臨時版本
在私人維護 Discord 頻道中發布您正在處理的相關訊息
發送解決問題的 Pull Request
合併 PR 前等待最長一天（合理範圍內）以取得核准
觸發私人發布工作流程以產生新發布
在相同的議題中發布連結至剛發布版本

重大版本​

1. 預發布準備​

1a. 共享組態變更​

1b. 自願社區測試​

1c. 在社區測試後進行組態微調​

2. 合併重大變更​

3. 版本發佈​

臨時發布​