Skip to content

docs(standard): the curated entry goes in the release pull request's body too #6

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

Merged
siracozmen01 merged 2 commits into from
Oct 24, 2026
Merged

docs(standard): the curated entry goes in the release pull request's body too #6

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1761d74
docs(standard): the curated entry goes in the release pull request's …
siracozmen01 Oct 24, 2026
4644cb2
docs(standard): curate the release last
siracozmen01 Oct 24, 2026
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
2 changes: 1 addition & 1 deletion docs/repository-standard.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -197,7 +197,7 @@ A repository's `ci.yml` lists what to check; the organization's reusable workflo
- Versions follow Semantic Versioning. Tags are `vX.Y.Z`.
- A change that breaks the API or ABI, or gives existing inputs a different result, carries `!` in its title and a `BREAKING CHANGE:` footer naming what changed, whatever its type. Before 1.0, release-please makes it a minor release (`bump-minor-pre-major`), never a patch, and the footer puts it in the changelog.
- Before merging a release pull request, the manager checks that its tag does not exist yet.
- release-please keeps a release pull request open from the conventional commits. It runs with a token of the organization's Rawframe Release GitHub App (`vars.RELEASE_APP_CLIENT_ID`, `secrets.RELEASE_APP_PRIVATE_KEY`), not `github.token`, because GitHub starts no CI for pull requests `github.token` opens and the release pull request must pass the required checks. Before merging it, the session rewrites its changelog entry into user language: what changed for someone using the product, grouped as Added, Changed, Fixed, Removed, Security. Internal refactors and test changes are left out.
- release-please keeps a release pull request open from the conventional commits. It runs with a token of the organization's Rawframe Release GitHub App (`vars.RELEASE_APP_CLIENT_ID`, `secrets.RELEASE_APP_PRIVATE_KEY`), not `github.token`, because GitHub starts no CI for pull requests `github.token` opens and the release pull request must pass the required checks. Before merging it, the session rewrites its changelog entry into user language: what changed for someone using the product, grouped as Added, Changed, Fixed, Removed, Security. Internal refactors and test changes are left out. The same entry replaces the notes in the pull request's body, between release-please's `---` lines, because release-please publishes the GitHub release notes from the body, not from CHANGELOG.md. release-please rewrites both whenever anything else lands on `main`, so the curation is the last change before the merge.
- Merging the release pull request tags the version and publishes the GitHub release with the same notes. Every release carries its files, a `SHA256SUMS` file, an SPDX SBOM and a build provenance attestation (`workflow-templates/release.yml`), so a user can check what they downloaded and where it was built.
- Every repository restarts at `0.0.1` when it migrates. Its old tags and GitHub releases are deleted, its changelog starts fresh with the `0.0.1` entry written in user language, and other repositories that pin it by tag move to the new tag. Git history keeps everything that came before.

Expand Down