From 7b08bc760ae86cc42765bb16cb01f8cb9e16188e Mon Sep 17 00:00:00 2001 From: qiancai Date: Thu, 3 Sep 2026 16:03:50 +0800 Subject: [PATCH 1/2] release notes: classify security dependency fixes --- scripts/release-notes-ai-generator/prompts/release-note.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/release-notes-ai-generator/prompts/release-note.md b/scripts/release-notes-ai-generator/prompts/release-note.md index 31f53cc1bdad3..ec13d1808133c 100644 --- a/scripts/release-notes-ai-generator/prompts/release-note.md +++ b/scripts/release-notes-ai-generator/prompts/release-note.md @@ -19,6 +19,7 @@ Write a release note when the change is visible to TiDB users or operators, incl - Meaningful performance improvements observable in common operations. - Behavior changes that affect upgrade paths, tooling integration, or operational workflows. - Default value changes for system variables or configuration parameters. +- Security fixes that address known or reported vulnerabilities in dependencies shipped with TiDB components, even when only dependency manifests or lockfiles change and functional behavior remains unchanged. Return a no-release-note verdict for internal-only changes, including: @@ -30,6 +31,8 @@ Return a no-release-note verdict for internal-only changes, including: If a PR is mostly internal but the outcome is user-visible, describe the outcome and omit implementation details. If the only user-facing effect is indirect or speculative, lean toward `not_needed`. +Do not classify a security dependency update as internal-only solely because it changes only dependency manifests or lockfiles. Return `not_needed` only when the affected dependencies are used exclusively by tests, development or build tooling, or other code not shipped with the product. + First, use all available context to decide whether the change needs a release note. If it does, classify it as follows: - When `issue_type_from_excel` is non-empty, use it as the primary basis for choosing between `bug_fix` and `improvement`. Map values containing `bug` or `fix` to `bug_fix`, and values containing `improvement` or `enhancement` to `improvement`, case-insensitively. Use the issue, PR, changed-file summary, and Excel draft only as supporting context for understanding the user impact and writing an accurate entry. Do not override a type that maps clearly from `issue_type_from_excel` merely because the other context could support another classification. From 8b1338bea300a5ea90cb4938dcc128a087e159eb Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Thu, 3 Sep 2026 16:18:43 +0800 Subject: [PATCH 2/2] Apply suggestions from code review --- scripts/release-notes-ai-generator/prompts/release-note.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/release-notes-ai-generator/prompts/release-note.md b/scripts/release-notes-ai-generator/prompts/release-note.md index ec13d1808133c..39c775e502e34 100644 --- a/scripts/release-notes-ai-generator/prompts/release-note.md +++ b/scripts/release-notes-ai-generator/prompts/release-note.md @@ -19,7 +19,7 @@ Write a release note when the change is visible to TiDB users or operators, incl - Meaningful performance improvements observable in common operations. - Behavior changes that affect upgrade paths, tooling integration, or operational workflows. - Default value changes for system variables or configuration parameters. -- Security fixes that address known or reported vulnerabilities in dependencies shipped with TiDB components, even when only dependency manifests or lockfiles change and functional behavior remains unchanged. +- Security fixes that address known or reported vulnerabilities affecting dependencies used by TiDB components shipped to users, even when only dependency manifests or lockfiles change and functional behavior remains unchanged. Return a no-release-note verdict for internal-only changes, including: @@ -31,7 +31,7 @@ Return a no-release-note verdict for internal-only changes, including: If a PR is mostly internal but the outcome is user-visible, describe the outcome and omit implementation details. If the only user-facing effect is indirect or speculative, lean toward `not_needed`. -Do not classify a security dependency update as internal-only solely because it changes only dependency manifests or lockfiles. Return `not_needed` only when the affected dependencies are used exclusively by tests, development or build tooling, or other code not shipped with the product. +Do not classify a security dependency update as internal-only solely because it changes only dependency manifests or lockfiles. Return `not_needed` if the dependency is used only by tests, development or build tooling, or other unshipped code, or if the vulnerability does not affect the shipped component. First, use all available context to decide whether the change needs a release note. If it does, classify it as follows: