Skip to content

Update release notes lifecycle #8816

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
Damyan Pepper (damyanp) wants to merge 1 commit into
base: main
Choose a base branch
from
+51 −402
Draft

Update release notes lifecycle #8816

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 11 additions & 1 deletion .github/ISSUE_TEMPLATE/release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,10 @@ we are confident we can generate builds for the new branch
## After Fork

- [ ] Update README.md if necessary
- [ ] Create draft of Release post on GitHub
- [ ] Create a draft GitHub Release using the applicable section of
`docs/ReleaseNotes.md`
- For a non-preview release, use `Upcoming Release`.
- For a preview release, use `Upcoming Preview Release`.

## Quality Sign Off

Expand All @@ -60,6 +63,13 @@ we are confident we can generate builds for the new branch
## Release

- [ ] Tag final release and post binaries
- [ ] Publish the GitHub Release
- [ ] Open a dedicated pull request to `main` that removes the published notes
from `docs/ReleaseNotes.md` and restores the applicable empty `Upcoming`
section
- A non-preview release clears only `Upcoming Release`.
- A preview release clears only `Upcoming Preview Release`.
- Leave the other upcoming section unchanged.
- [ ] Add the new compiler to Compiler Explorer
- [ ] Email LunarG the release tag and update the release spreadsheet.
- [ ] Publish the new compiler NuGet package.
Expand Down
9 changes: 9 additions & 0 deletions .github/copilot-instructions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,10 @@ Use the release note policy in `CONTRIBUTING.md` ("Release Notes") as the defaul
- Release notes are expected for user-visible, significant compiler behavior changes.
- Common examples include new features (language, hardware support, compiler options), important isolated bug fixes, and changes in default behavior.
- Release notes are often not needed for refactors, test-only updates, or infrastructure-only changes unless user-visible behavior changes.
- Ordinary changes belong in `Upcoming Release`, even if they first ship in a preview build.
- Only changes to experimental or preview-only features belong in `Upcoming Preview Release`.
- When a preview feature graduates, its supported behavior should be described in `Upcoming Release`.
- Published release notes belong in the corresponding GitHub Release, not in `docs/ReleaseNotes.md`.

Account for multi-PR efforts:
- If a PR appears to be one part of a larger tracked effort, recognize that a single shared release note may be intentional.
Expand All @@ -27,6 +31,11 @@ When reviewing an existing release note:
- Use `### Upcoming Preview Release` only for changes that apply exclusively to experimental preview shader models.
- Do not add entries to an already named release unless the change explicitly targets that release.

When reviewing a post-release cleanup:
- Confirm that the GitHub Release has been published before its notes are removed.
- Confirm that the cleanup targets `main`, restores the applicable empty `Upcoming` section, and leaves the other upcoming section unchanged.
- A non-preview release clears only `Upcoming Release`; a preview release clears only `Upcoming Preview Release`.

Comment tone:
- Use a stronger ask when the PR clearly appears to be a user-visible bug fix or feature.
- If release-note coverage may come in a related PR (including a future PR), ask the author to point to that planned coverage.
Expand Down
21 changes: 16 additions & 5 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -127,11 +127,22 @@ These include changes that are:
When such a change is made, the release note should be included as part of that change.
This is done in the docs/ReleaseNotes.md file.

If the change is meant for a named release, it should be added to that named release's section of the release notes file.
As the change is merged to the appropriate release branches, the release notes will come along with it.

If a change is meant for the next upcoming release, it should be added to the "Upcoming Release" section.
When the next upcoming release is named, the title will be updated and the release note will be included in the appropriate release.
`docs/ReleaseNotes.md` contains notes only for releases that have not been
published. Published notes are archived in the corresponding
[GitHub Release](https://github.com/microsoft/DirectXShaderCompiler/releases).

Add ordinary changes to **Upcoming Release**, even if they will first appear in
a preview build. Add only changes to experimental or preview-only features to
**Upcoming Preview Release**. When a preview feature becomes supported in a
non-preview release, add a note describing that supported feature to
**Upcoming Release**.

The release team may rename the applicable upcoming section when a release is
named. After the GitHub Release is published, a dedicated pull request to
`main` removes that release's notes and restores the empty upcoming section.
A non-preview release clears only **Upcoming Release**; a preview release
clears only **Upcoming Preview Release**. The other section must remain
unchanged.

When writing release note list entries:

Expand Down
Loading
Loading