Move change-note documentation to unreleased-change-notes/README.md

This commit is contained in:
Mario Campos
2026-10-08 12:48:24 -05:00
parent 38fee79b02
commit 2a935ca93d
2 changed files with 49 additions and 52 deletions

View File

@@ -53,7 +53,7 @@ Here are a few things you can do that will increase the likelihood of your pull
- Write tests.
- Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
- Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
- For user-facing changes, add a [change-note](#change-notes).
- For user-facing changes, add a change-note file. See [unreleased-change-notes/README.md](unreleased-change-notes/README.md).
## Releasing (write access required)
@@ -130,57 +130,6 @@ To deprecate an older version of the Action:
1. Upgrade the Actions warning for customers using the deprecated version to a non-fatal error, and mention that this version of the Action is no longer supported.
1. Make a PR to bump the `OLDEST_SUPPORTED_MAJOR_VERSION` in [config.ts](pr-checks/config.ts). Once this PR is merged, the release process will no longer backport changes to the deprecated release version.
## Change-notes
Change-notes are Markdown files used to document user-facing changes. When making a change that affects users, create a change-note file in `unreleased-change-notes/` that describes the change. At the next release, the change-note files in `unreleased-change-notes/` will be combined into a new entry in `CHANGELOG.md`.
### Change-note file format
Change-note files must follow a certain format so that they can be automatically validated and processed. Failure to follow the format will result in a failed PR check.
You may validate your change-note file locally by running `npx tsx pr-checks/changenotes.ts validate`. This command will scan all change-note files in `unreleased-change-notes/` and report any errors.
#### File name
Change-note files must be named according to the following pattern: `YYYY-MM-DD-<short-title>.md`, where `YYYY-MM-DD` is the date of the change and `<short-title>` is a short description of the change. The `<short-title>` must contain only lowercase letters (`a-z`), digits (`0-9`), and hyphens (`-`), and must start with a letter or digit. Hyphens may be used to separate words. For example, a change-note file for a JSON-related bug fix that was made on January 1st, 2020 might be named `2020-01-01-fix-json-bug.md`.
#### Frontmatter
The first line of the file must be a YAML frontmatter block, which is delimited by lines containing three dashes (`---`). The frontmatter block must contain a single `category` field, whose value must be one of the following categories:
| Category | Description |
| -------- | ----------- |
| `breaking` | A change that introduces backward-incompatible behavior. |
| `feature` | A new capability or behavior added to the Action. |
| `improvement` | An enhancement to existing functionality or performance. |
| `securityFix` | A change that addresses a security vulnerability. |
| `fix` | A bug fix that corrects unexpected behavior. |
| `unship` | Features or options that have been removed. |
| `deprecation` | Deprecation of features that will be removed in future versions. |
| `knownIssue` | A known issue or limitation in the current release. |
| `misc` | Other changes that do not fit into other categories. |
#### Body
The body of the change-note file must:
- Be written in valid [GitHub-Flavored Markdown](https://github.github.com/gfm/).
- Describe the change in a way that is understandable to users of the Action. Limit the description to 1-2 sentences, and avoid technical details that are not relevant to users.
- Be structured as a single unordered Markdown list with hyphen (`-`) bullets. Each list item should describe a single change. If there are multiple changes, use multiple list items.
### Example change-note file
```
---
category: feature
---
- Added support for the SARIF v2.2 specification in the `github/codeql-action/upload` Action.
- Added a new `sarif-version` input to the `github/codeql-action/upload` Action, allowing users to specify the SARIF version to use when uploading results.
```
## Resources
- [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)

View File

@@ -0,0 +1,48 @@
## unreleased-change-notes
Change-notes are Markdown files used to document user-facing changes. When making a change that affects users, create a change-note file here that describes the change. At the next release, the change-note files in `unreleased-change-notes/` will be combined into a new entry in `CHANGELOG.md`.
### Change-note file format
Change-note files must follow a certain format so that they can be automatically validated and processed. Failure to follow the format will result in a failed PR check.
You may validate your change-note file locally by running `npx tsx pr-checks/changenotes.ts validate`. This command will scan all change-note files in `unreleased-change-notes/` and report any errors.
#### File name
Change-note files must be named according to the following pattern: `YYYY-MM-DD-<short-title>.md`, where `YYYY-MM-DD` is the date of the change and `<short-title>` is a short description of the change. The `<short-title>` must contain only lowercase letters (`a-z`), digits (`0-9`), and hyphens (`-`), and must start with a letter or digit. Hyphens may be used to separate words. For example, a change-note file for a JSON-related bug fix that was made on January 1st, 2020 might be named `2020-01-01-fix-json-bug.md`.
#### Frontmatter
The first line of the file must be a YAML frontmatter block, which is delimited by lines containing three dashes (`---`). The frontmatter block must contain a single `category` field, whose value must be one of the following categories:
| Category | Description |
| -------- | ----------- |
| `breaking` | A change that introduces backward-incompatible behavior. |
| `feature` | A new capability or behavior added to the Action. |
| `improvement` | An enhancement to existing functionality or performance. |
| `securityFix` | A change that addresses a security vulnerability. |
| `fix` | A bug fix that corrects unexpected behavior. |
| `unship` | Features or options that have been removed. |
| `deprecation` | Deprecation of features that will be removed in future versions. |
| `knownIssue` | A known issue or limitation in the current release. |
| `misc` | Other changes that do not fit into other categories. |
#### Body
The body of the change-note file must:
- Be written in valid [GitHub-Flavored Markdown](https://github.github.com/gfm/).
- Describe the change in a way that is understandable to users of the Action. Limit the description to 1-2 sentences, and avoid technical details that are not relevant to users.
- Be structured as a single unordered Markdown list with hyphen (`-`) bullets. Each list item should describe a single change. If there are multiple changes, use multiple list items.
### Example change-note file
```
---
category: feature
---
- Added support for the SARIF v2.2 specification in the `github/codeql-action/upload` Action.
- Added a new `sarif-version` input to the `github/codeql-action/upload` Action, allowing users to specify the SARIF version to use when uploading results.
```