リリースノートを種別ごとに並べる

.github/workflows/docs.yml

@@ -12,6 +12,8 @@ on:
       - "build/verify-markdown-tables.ps1"
       - "build/verify-readme-counts.ps1"
       - "build/verify-analyzer-releases.ps1"
+      - "build/verify-release-note-categories.ps1"
+      - "build/generate-release-notes.ps1"
       - "src/ComputeWeave.SourceGenerators/Diagnostics/DiagnosticDescriptors.cs"
       - "src/ComputeWeave.D2D1.SourceGenerators/Diagnostics/DiagnosticDescriptors.cs"
   pull_request:
@@ -23,6 +25,8 @@ on:
       - "build/verify-markdown-tables.ps1"
       - "build/verify-readme-counts.ps1"
       - "build/verify-analyzer-releases.ps1"
+      - "build/verify-release-note-categories.ps1"
+      - "build/generate-release-notes.ps1"
       - "src/ComputeWeave.SourceGenerators/Diagnostics/DiagnosticDescriptors.cs"
       - "src/ComputeWeave.D2D1.SourceGenerators/Diagnostics/DiagnosticDescriptors.cs"
 
@@ -52,3 +56,8 @@ jobs:
       # 重大度が動いた規則を追加した規則と同じ形で移すと、構築は通るのに履歴が二重になる。
       - name: アナライザーのリリース記録を検証
         run: pwsh build/verify-analyzer-releases.ps1
+
+      # ラベルの改名も種別の追加も Markdown の側で起きる。ノートの側が置き去りになると、
+      # 出荷して初めて分かる。
+      - name: リリースノートの種別を検証
+        run: pwsh build/verify-release-note-categories.ps1

.github/workflows/quick-release.yml

@@ -263,6 +263,10 @@ jobs:
       - name: README の件数を検証
         run: pwsh build/verify-readme-counts.ps1
 
+      # 種別の食い違いはノートを作る工程まで現れない。そこは公開の後なので、公開の前に確かめる。
+      - name: リリースノートの種別を検証
+        run: pwsh build/verify-release-note-categories.ps1
+
       - name: パッケージをアーティファクトとして保存
         uses: actions/upload-artifact@v4
         with:
@@ -501,6 +505,8 @@ jobs:
     if: ${{ inputs.create_release }}
     permissions:
       contents: write
+      # ノートは併合済みプルリクエストのラベルを読んで種別ごとに並べる。
+      pull-requests: read
     defaults:
       run:
         shell: bash
@@ -517,35 +523,19 @@ jobs:
           name: nuget-packages
           path: ./artifacts
 
-      - name: コミット履歴からリリースノートを生成
+      # 見出しをそのまま並べると、上げる側に効く数件が二百件の中に埋もれる。
+      # このワークフローは手動でしか起動せず、手元でもCIでも走らない。生成をタグ側と同じ
+      # script に寄せてあるので、片方だけが古くなることが無い。
+      - name: リリースノートを生成
         env:
-          CURRENT_TAG: v${{ needs.validate.outputs.version }}
-          CURRENT_SHA: ${{ github.sha }}
-          VERSION: ${{ needs.validate.outputs.version }}
+          GH_TOKEN: ${{ github.token }}
         run: |
-          PREV=$(git tag --merged "${CURRENT_SHA}" --sort=-version:refname \
-            | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' \
-            | grep -Fxv "${CURRENT_TAG}" \
-            | head -n 1 || true)
-          if [ -n "${PREV}" ]; then
-            LOG=$(git log "${PREV}..${CURRENT_SHA}" --pretty=format:"- %s (%h)" --no-merges --)
-          else
-            LOG=$(git log -n 30 --pretty=format:"- %s (%h)" --no-merges)
-          fi
-          {
-            echo "### 変更内容"
-            printf '%s\n' "${LOG:-変更履歴を取得できませんでした。}"
-            echo ""
-            echo "### インストール"
-            echo '```sh'
-            echo "dotnet add package ComputeWeave --version ${VERSION}"
-            echo '```'
-            echo ""
-            echo "### NuGet"
-            echo "https://www.nuget.org/packages/ComputeWeave/${VERSION}"
-            echo ""
-            echo "テストは実行していません。パッケージ作成時のビルドだけを実行しています。"
-          } > release-notes.md
+          pwsh build/generate-release-notes.ps1 \
+            -Version "${{ needs.validate.outputs.version }}" \
+            -CurrentTag "v${{ needs.validate.outputs.version }}" \
+            -CurrentSha "${{ github.sha }}" \
+            -Repository "${{ github.repository }}" \
+            -TestsNotRun
 
       # タグは GITHUB_TOKEN で作られるため release.yml は起動しない。
       - name: GitHub Release を作成してパッケージを添付

.github/workflows/release.yml

@@ -291,6 +291,10 @@ jobs:
       - name: README の件数を検証
         run: pwsh build/verify-readme-counts.ps1
 
+      # 種別の食い違いはノートを作る工程まで現れない。そこは公開の後なので、公開の前に確かめる。
+      - name: リリースノートの種別を検証
+        run: pwsh build/verify-release-note-categories.ps1
+
       - name: パッケージをアーティファクトとして保存
         uses: actions/upload-artifact@v4
         with:
@@ -426,6 +430,8 @@ jobs:
     needs: [validate, pack, publish-nuget]
     permissions:
       contents: write
+      # ノートは併合済みプルリクエストのラベルを読んで種別ごとに並べる。
+      pull-requests: read
     defaults:
       run:
         shell: bash
@@ -442,33 +448,17 @@ jobs:
           name: nuget-packages
           path: ./artifacts
 
-      - name: コミット履歴からリリースノートを生成
+      # 見出しをそのまま並べると、上げる側に効く数件が二百件の中に埋もれる。
+      # 生成は高速リリースと同じ script が行う。二重に書くと片方だけが古くなる。
+      - name: リリースノートを生成
         env:
-          CURRENT_TAG: ${{ github.ref_name }}
-          VERSION: ${{ needs.validate.outputs.version }}
+          GH_TOKEN: ${{ github.token }}
         run: |
-          CURRENT_SHA=$(git rev-parse HEAD)
-          PREV=$(git tag --merged "${CURRENT_SHA}" --sort=-version:refname \
-            | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' \
-            | grep -Fxv "${CURRENT_TAG}" \
-            | head -n 1 || true)
-          if [ -n "${PREV}" ]; then
-            LOG=$(git log "${PREV}..${CURRENT_SHA}" --pretty=format:"- %s (%h)" --no-merges --)
-          else
-            LOG=$(git log -n 30 --pretty=format:"- %s (%h)" --no-merges)
-          fi
-          {
-            echo "### 変更内容"
-            printf '%s\n' "${LOG:-変更履歴を取得できませんでした。}"
-            echo ""
-            echo "### インストール"
-            echo '```sh'
-            echo "dotnet add package ComputeWeave --version ${VERSION}"
-            echo '```'
-            echo ""
-            echo "### NuGet"
-            echo "https://www.nuget.org/packages/ComputeWeave/${VERSION}"
-          } > release-notes.md
+          pwsh build/generate-release-notes.ps1 \
+            -Version "${{ needs.validate.outputs.version }}" \
+            -CurrentTag "${{ github.ref_name }}" \
+            -CurrentSha "${{ github.sha }}" \
+            -Repository "${{ github.repository }}"
 
       - name: GitHub Release を作成してパッケージを添付
         uses: softprops/action-gh-release@v3

CONTRIBUTING.md

@@ -162,7 +162,7 @@ Throughout, distinguish what you observed, what you derived from reading the cod
 
 ### Labels
 
-Apply the label that matches each kind you kept in the template. The kinds and the labels correspond one for one: `bug`, `public api`, `behavior change`, `performance`, `analyzer or generator`, `documentation` and `build and ci`. Nothing applies them for you, and the automated check described below does not set them. Labels are how the merged history is filtered by kind, so a pull request that declares a kind and carries no label is invisible to that filter.
+Apply the label that matches each kind you kept in the template. The kinds and the labels correspond one for one: `bug`, `public api`, `behavior change`, `performance`, `analyzer or generator`, `documentation` and `build and ci`. Nothing applies them for you, and the automated check described below does not set them. Labels are how the merged history is filtered by kind, so a pull request that declares a kind and carries no label is invisible to that filter. They also decide where the pull request appears in the notes of the next release: the notes group the merged pull requests of a release by these labels, in the order a caller upgrading reads them, and a pull request carrying none of them is listed apart from the grouped ones.
 
 ### Automated checks