Skip to content

Commit 4a03e8b

Browse files
committed
Rotate release notes as part of the 0.6.6 release
1 parent 0a47531 commit 4a03e8b

2 files changed

Lines changed: 22 additions & 22 deletions

File tree

.release-notes/0.6.6.md

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
## Add `create-empty-github-release` entrypoint
2+
3+
There is a new `create-empty-github-release` entrypoint that creates an empty GitHub release for the tag being released. This lets release workflows attach build artefacts to the GitHub release as they are produced, rather than waiting until `publish-release-notes-to-github` runs to create the release.
4+
5+
If a release already exists for the tag, `create-empty-github-release` leaves it alone, so the entrypoint is safe to run from a restarted release workflow.
6+
7+
Example use:
8+
9+
```yaml
10+
- name: Create empty GitHub release
11+
uses: docker://ghcr.io/ponylang/release-bot-action:X.Y.Z
12+
with:
13+
entrypoint: create-empty-github-release
14+
env:
15+
RELEASE_TOKEN: ${{ secrets.RELEASE_TOKEN }}
16+
```
17+
18+
## GitHub's `releases/latest` URL now points to the newest release
19+
20+
`publish-release-notes-to-github` now enables GitHub's default "latest release" selection (by semantic version and creation date) when it publishes release notes. Previously, `https://github.com/OWNER/REPO/releases/latest` did not reliably point to the most recent release for repositories using this action.
21+
22+
Re-running the announcement workflow against an older tag will not flip the `releases/latest` pointer away from a newer release — GitHub continues to pick the newest release by semver and date.

.release-notes/next-release.md

Lines changed: 0 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -1,22 +0,0 @@
1-
## Add `create-empty-github-release` entrypoint
2-
3-
There is a new `create-empty-github-release` entrypoint that creates an empty GitHub release for the tag being released. This lets release workflows attach build artefacts to the GitHub release as they are produced, rather than waiting until `publish-release-notes-to-github` runs to create the release.
4-
5-
If a release already exists for the tag, `create-empty-github-release` leaves it alone, so the entrypoint is safe to run from a restarted release workflow.
6-
7-
Example use:
8-
9-
```yaml
10-
- name: Create empty GitHub release
11-
uses: docker://ghcr.io/ponylang/release-bot-action:X.Y.Z
12-
with:
13-
entrypoint: create-empty-github-release
14-
env:
15-
RELEASE_TOKEN: ${{ secrets.RELEASE_TOKEN }}
16-
```
17-
18-
## GitHub's `releases/latest` URL now points to the newest release
19-
20-
`publish-release-notes-to-github` now enables GitHub's default "latest release" selection (by semantic version and creation date) when it publishes release notes. Previously, `https://github.com/OWNER/REPO/releases/latest` did not reliably point to the most recent release for repositories using this action.
21-
22-
Re-running the announcement workflow against an older tag will not flip the `releases/latest` pointer away from a newer release — GitHub continues to pick the newest release by semver and date.

0 commit comments

Comments
 (0)