You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Support prerelease releases: update GitHub Release notes only (no CHANGELOG.md or PR)
- Stable releases: update both CHANGELOG.md (via PR) and GitHub Release notes
- Don't include version heading in GitHub Release notes (redundant with release title)
- Omit 'Other changes' subheading when there are no highlighted features
- Add 'New contributors' section for first-time contributors
- Trigger changelog workflow from publish.yml for both latest and prerelease
- Remove release:published trigger (GITHUB_TOKEN events don't trigger other workflows)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
You are an AI agent that generates a well-formatted changelog when a new stable release of the Copilot SDK is published. You update `CHANGELOG.md` in the repository and create a PR with the changes.
31
+
You are an AI agent that generates well-formatted release notes when a release of the Copilot SDK is published.
32
+
33
+
-**For stable releases** (tag has no prerelease suffix like `-preview`): update `CHANGELOG.md` via a PR AND update the GitHub Release notes.
34
+
-**For prerelease releases** (tag contains `-preview` or similar suffix): update the GitHub Release notes ONLY. Do NOT modify `CHANGELOG.md` or create a PR.
35
+
36
+
Determine which type of release this is by inspecting the tag or fetching the release metadata.
For `workflow_dispatch` runs, the `github.event.release.*` fields will be empty. In that case, use the GitHub API to fetch the release corresponding to `inputs.tag` to get its name, publish date, and other metadata.
43
+
Use the GitHub API to fetch the release corresponding to `${{ github.event.inputs.tag }}` to get its name, publish date, prerelease status, and other metadata.
43
44
44
45
## Your Task
45
46
46
47
### Step 1: Identify the version range
47
48
48
-
1. The **new version** is the release tag: `${{ github.event.release.tag_name || inputs.tag }}`
49
-
2. Read `CHANGELOG.md` and find the **most recent version heading** (a line matching `## [vX.Y.Z](...)`). Extract that version tag — this is the last documented release.
50
-
3. If `CHANGELOG.md` has no version entries yet, find the previous stable release by listing releases and picking the most recent non-prerelease release before this one. If none exist, use the first commit in the repo as the starting point.
49
+
1. The **new version** is the release tag: `${{ github.event.inputs.tag }}`
50
+
2. Fetch the release metadata to determine if this is a **stable** or **prerelease** release.
51
+
3. Determine the **previous version** to diff against:
52
+
-**For stable releases**: find the previous **stable** release (skip prereleases). Check `CHANGELOG.md` for the most recent version heading (`## [vX.Y.Z](...)`), or fall back to listing releases via the API. This means stable changelogs include ALL changes since the last stable release, even if some were already mentioned in prerelease notes.
53
+
-**For prerelease releases**: find the most recent release of **any kind** (stable or prerelease) that precedes this one. This way prerelease notes only cover what's new since the last release.
54
+
4. If no previous release exists at all, use the first commit in the repo as the starting point.
51
55
52
56
### Step 2: Gather changes
53
57
@@ -72,7 +76,9 @@ Only include changes that are **user-visible in the published SDK packages**. Sk
72
76
73
77
Additionally, identify **new contributors** — anyone whose first merged PR to this repo falls within this release range. You can determine this by checking whether the author has any earlier merged PRs in the repository.
0 commit comments