メインコンテンツにスキップ

リリース

ユーザー > リリースは、自動リリースの実行方法について説明しています。通常、毎週のリリースにメンテナンス作業を行う必要はありません。

ただし、まれに手動による作業が必要となる2種類のリリースがあります。

メジャーリリース​

ユーザー > リリース > メジャーリリースに従って、累積された破壊的変更を含むメジャーバージョンをまれにリリースします。

1. リリース前の準備​

  1. リリースの名前でマイルストーンを作成します [例: マイルストーン 6.0.0]。
  2. 推奨ルール設定の変更に関する課題がまだ存在しない場合は、作成します [例: 5.0.0の`recommended`セットの変更]。
  3. リリース対象の破壊的変更をそのマイルストーンに追加します。
  4. 非推奨のコードや新しいメジャーバージョンのTODOについて言及しているソースコードのコメント (`CHANGELOG.md`ファイルを除く) を検索し、対応する課題をそのマイルストーンに作成します。
    • たとえば、新しいメジャーバージョン8の場合、検索には次のようなものが含まれる場合があります
      • /deprecated|todo/i
      • /v8/i
      • /todo.*v?8/i
  5. 依存関係の最小バージョンを上げるための課題を作成します [例: 拡張: v8の依存関係の最小バージョンを上げる]
  6. プロジェクトリポジトリ (個人のフォークではない) の`main`から2つの新しいブランチを作成します
    • v${major}
    • v${major}-canary-auto-release
  7. `v${major}-canary-auto-release`から`main`へのPRを raise し、`ci.yml`ワークフローとREADME.mdを変更します [例: chore: v6の自動カナリアリリースを追加]
    • ci.yml:
      • ファイルの先頭にある`push:` > `branches:`の下に、`- v${major}`リスト項目を追加します。
      • `publish_canary_version`と同じ`publish_canary_version_v${major}`ステップを追加しますが、以下を除きます
        • `if`条件のブランチチェックを`if: github.ref == 'refs/heads/v${major}'`に変更します。
        • その公開コマンドは`npx nx release publish --tag rc-v${major} --verbose`にする必要があります。
    • README.md:
      • ブランチ用にNetlifyに作成した`v${major}--typescript-eslint.netlify.app`プレビューデプロイ環境へのリンクを追加します。
    • レビューが完了したら、これを`main`にマージし、`v${major}`ブランチをリベースします。

1a. 共有設定の変更​

メジャーバージョンは、安定した`recommended*`および`stylistic*`設定の値を変更する唯一の機会です。メジャーバージョンの一般的なPRフローと並行して

  1. typescript-eslint Discordに`v${major}`チャネルを作成します
  2. 提案されたルールの変更をまとめた表を含むディスカッションを作成します [例: 6.0.0の設定の変更]。
  3. そのディスカッションをtypescript-eslint Discordとソーシャルメディアに投稿します
  4. (1か月)と(ディスカッションの落ち着き)のどちらか大きい方が経過したら、課題を提出し、対応する変更を行う`v${major}`ブランチに対応するPRを送信します [例: 設定: v6の設定プリセットに変更を適用する]。

1b. 自発的なコミュニティテスト​

共有設定の変更作業と並行して、ベータ版を試してみる意思のある一般的なコミュニティプロジェクトでベータ版をテストしてください。

  1. 消費者が新しいバージョンのベータ版を試すことができるように、固定された課題を作成します [例: さまざまな影響力のあるコミュニティリポジトリでv8ベータ版を試す]。
    • 各コミュニティプロジェクトに、Discordや課題トラッカーなどで、新しいバージョンを試してみることに興味があるかどうかを尋ねます。
    • PRを受け取る意思を示した各コミュニティプロジェクトは、PRを受け取る必要があります。
  2. 提案された*共有設定の変更*が`v${major}`ブランチにマージされたら、新しいベータバージョンを含むドラフトPRを各プロジェクトに送信します。

1c. コミュニティテスト後の設定の微調整​

コミュニティテストの一環として、プリセット設定に追加の変更が発見される場合があります。その場合は

  1. 提案された変更を説明するディスカッションを作成します [例: 設定: v6の設定の「最終」変更の最終ラウンド]。
  2. この新しいディスカッションを、以前の設定変更のディスカッション、typescript-eslint Discord、およびソーシャルメディアに投稿します。
  3. (2週間)と(ディスカッションの落ち着き)のどちらか大きい方が経過したら

可能であれば、2回目の設定変更は避けたいと考えています。これらは、コミュニティテストで一貫して発生するフィードバックに対してのみ行う必要があります。

2. 破壊的変更のマージ​

  1. `v${major}`から`main`へのPRを送信します [例: v6.0.0]。
  2. すべて破壊的変更PRのターゲットブランチを`v${major}`に変更します。
    • これらの変更を破壊的変更として示すために、PR説明の最初の行は`BREAKING CHANGE:`と読み、2行目は変更を簡単に要約する必要があります。
    • マージされたコミットメッセージにも、`nx release`がリリースノートで破壊的変更として認識するために、最初の行に`BREAKING CHANGE:`を含める必要があることに注意することが重要です。これを忘れると、リリースドキュメントを書く際に手作業が増えることになります。
  3. 新しいベータ版を発表するブログ記事を書いて共有します [例: ドキュメント: v5->v6の変更と移行戦略を説明するブログ記事]。
    • `v${major}`ブランチに変更が加わるにつれて、この投稿を最新の状態に保ちます。
  4. 必要なすべてのPRがマージされるまで待ちます
  5. 新しいリリースを発表するブログ記事 [例: ドキュメント: v6のリリースブログ記事] を作成し、`v${major}`ブランチに配置します。
  6. アーリーアダプターがテストを支援し、変更について話し合う時間を確保するために、リリースを**少なくとも1週間**待機させます。
    • さらに注目を集めるために、`@tseslint` Twitterで宣伝します。
  7. ディスカッションが落ち着いたら、リポジトリのそのマージ設定を一時的に有効にすることで、PRを`main`の上に従来のマージコミットします。
注意

*破壊的でない*変更は、`main`またはメジャーブランチにマージできます。特別な処理は必要ありません。

3. バージョンのリリース​

  1. メジャーリリースから発生する可能性のある問題に対処するため、担当者が出席できるよう、メンテナーと話し合って臨時リリースの準備をしましょう。手動で行うことで、確実に担当者に対応してもらえます。
  2. リリースノートを準備します。 nx release はGitHub上に自動的にリリースノートを生成しますが、これは整理されておらず、ユーザーにとって役に立ちません。破壊的な変更が最も目立つように、リリースノートを再編成して、上部に配置する必要があります。マイグレーションが必要な場合は、ユーザーが簡単に実行できるように手順をリストする必要があります。
  3. 最後に、GitHubリリースへのリンクを付けて、@tseslint のTwitterアカウントでリリースをツイートします。リリースのハイライトに関する追加情報を含めるようにしてください！

臨時リリース​

ユーザー > リリース > 臨時リリースに記載されているように、重大な不具合などの稀な緊急事態のために、手動で新しいリリースをトリガーする場合があります。その場合は、

  1. 関連するすべてのIssueに、臨時リリースをリリースする予定であることを記載します。
  2. 作業中であることを、非公開のメンテナンスDiscordチャンネルに投稿します。
  3. 問題を解決するプルリクエストを送信します。
  4. PRをマージする前に、最大1日（妥当な範囲で）承認を待ちます。
  5. 非公開リリースワークフローをトリガーして、新しいリリースを生成します。
  6. 新しくリリースされたバージョンへのリンクを付けて、同じIssueに返信します。