管理發佈
發佈是指專案正式發布新版本，以便社群可以使用它。發佈類型有兩種
- 遵循語意化版本控制且被視為可供生產環境使用的常規發佈。
- 不被視為可供生產環境使用，旨在讓社群預覽即將到來的變更的預先發佈。
發佈管理員
技術指導委員會 (TSC) 的一名成員被指派管理每次排定的發佈。發佈管理員在發佈前一天的 TSC 會議上決定。
發佈管理員負責
- 週五排定的發佈。
- 監控週末期間的議題。
- 確定週一是否需要發佈修補程式版本。
- 發佈修補程式版本（如有必要）。
發佈管理員應在發佈後的週一徵求整個團隊的意見，以再次確認是否需要發佈修補程式版本。
發佈管理員需要有權限存取 ESLint 的 npm 雙重驗證，才能進行發佈。
發佈溝通
每次排定的發佈都與自動產生的發佈議題相關聯 (範例)。發佈議題是團隊了解發佈狀態的資訊來源，並包含發佈管理員應遵循的檢查清單。
流程
在排定的發佈當天，發佈管理員應遵循發佈議題中的步驟。
所有與發佈相關的溝通都在 Discord 上 #team 頻道中的討論串中進行。
在排定的發佈後的週一，發佈管理員需要確定是否需要發佈修補程式版本。如果自排定的發佈以來發生以下任何情況，則認為需要發佈修補程式版本
- 迴歸錯誤導致人們的 lint 建置失敗，而之前是通過的。
- 任何導致使用者大量問題的錯誤（通常由於新功能而發生）。
修補程式版本的決定應盡可能在週一早些時候做出。如果需要發佈修補程式版本，則遵循與排定的發佈流程相同的步驟。
在極少數情況下，如果已知發佈存在嚴重的迴歸錯誤，並且週一尚未修復，則可能需要第二次修補程式版本。如果發生這種情況，發佈管理員應在發佈議題上宣布情況，並保持議題開啟，直到所有修補程式版本都完成為止。但是，通常最好在下一個發佈週期中修復錯誤，而不是進行第二次修補程式版本。
在修補程式版本發佈後（或不需要發佈修補程式版本），關閉發佈議題，並通知團隊他們可以再次開始合併 semver-minor 變更。
發佈參數
下表顯示在 Jenkins 上啟動 eslint-js Release (@eslint/js 套件發佈) 和 eslint Release (eslint 套件發佈) 工作以發佈具有最新功能的新版本時，可選擇作為 RELEASE_TYPE 的選項範例。在這兩個工作中，都應選擇 main 作為 RELEASE_BRANCH。
| HEAD 版本 | 期望的下一個版本 | eslint-js ReleaseRELEASE_TYPE |
|---|---|---|
9.25.0 |
9.25.1 |
patch |
9.25.0 |
9.26.0 |
minor |
9.25.0 |
10.0.0-alpha.0 |
alpha.0 |
10.0.0-alpha.0 |
10.0.0-alpha.1 |
alpha |
10.0.0-alpha.1 |
10.0.0-beta.0 |
beta |
10.0.0-beta.0 |
10.0.0-beta.1 |
beta |
10.0.0-beta.1 |
10.0.0-rc.0 |
rc |
10.0.0-rc.0 |
10.0.0-rc.1 |
rc |
10.0.0-rc.1 |
10.0.0 |
major |
| HEAD 版本 | 期望的下一個版本 | eslint ReleaseRELEASE_TYPE |
|---|---|---|
9.25.0 |
9.25.1 或 9.26.0 |
latest |
9.25.0 |
10.0.0-alpha.0 |
alpha |
10.0.0-alpha.0 |
10.0.0-alpha.1 |
alpha |
10.0.0-alpha.1 |
10.0.0-beta.0 |
beta |
10.0.0-beta.0 |
10.0.0-beta.1 |
beta |
10.0.0-beta.1 |
10.0.0-rc.0 |
rc |
10.0.0-rc.0 |
10.0.0-rc.1 |
rc |
10.0.0-rc.1 |
10.0.0 |
latest |
當發佈先前主要版本的較新版本時，可選擇作為 RELEASE_TYPE 的選項取決於 HEAD 版本是否為預先發佈版本。在這兩個工作中，都應選擇對應的開發分支（例如，v9.x-dev）作為 RELEASE_BRANCH。
| HEAD 版本 | 先前主要版本的較新版本 | 期望的下一個版本 | eslint-js ReleaseRELEASE_TYPE |
|---|---|---|---|
10.0.0-alpha.0 |
9.25.0 |
9.25.1 |
patch |
10.0.0-alpha.0 |
9.25.0 |
9.26.0 |
minor |
10.0.0 |
9.25.0 |
9.25.1 |
maintenance.patch |
10.0.0 |
9.25.0 |
9.26.0 |
maintenance.minor |
| HEAD 版本 | 先前主要版本的較新版本 | 期望的下一個版本 | eslint ReleaseRELEASE_TYPE |
|---|---|---|---|
10.0.0-alpha.0 |
9.25.0 |
9.25.1 或 9.26.0 |
latest |
10.0.0 |
9.25.0 |
9.25.1 或 9.26.0 |
maintenance |
緊急發佈
緊急發佈是未經計畫的，既不是定期排定的發佈，也不是預期的修補程式版本。
一般來說，我們盡量不進行緊急發佈。即使存在迴歸錯誤，最好等到週一，看看是否出現任何其他問題，以便修補程式版本可以修復盡可能多的問題。
唯一真正的例外是，如果 ESLint 對大多數目前使用者來說完全無法使用。例如，我們曾經推送一個對所有人來說都會出錯的版本，因為它缺少一些核心檔案。在這種情況下，緊急發佈是適當的。
疑難排解
npm publish 傳回 404
這通常是由於與 npm 權杖相關的權限錯誤而發生。
release-please使用在一年後過期的細緻存取權杖。此權杖與eslintbotnpm 帳戶關聯，需要每年三月重新產生。如果存取權杖已過期，npm publish會傳回 404。- Jenkins 使用沒有到期日的傳統存取權杖，但確實需要 2FA 代碼才能發佈。如果 2FA 代碼不正確，則
npm publish會傳回 404。