From 1761d74a806b23cceabc76182fd8c88da9b43d24 Mon Sep 17 00:00:00 2001 From: Sirac Ozmen Date: Sat, 24 Oct 2026 05:44:32 +0300 Subject: [PATCH 1/2] docs(standard): the curated entry goes in the release pull request's body too --- docs/repository-standard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/repository-standard.md b/docs/repository-standard.md index 587bc7f..895ef6a 100644 --- a/docs/repository-standard.md +++ b/docs/repository-standard.md @@ -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. - 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. From 4644cb2a7ced0f61f6d07bcbcc8cb0197fcc6624 Mon Sep 17 00:00:00 2001 From: Sirac Ozmen Date: Sat, 24 Oct 2026 05:45:39 +0300 Subject: [PATCH 2/2] docs(standard): curate the release last --- docs/repository-standard.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/repository-standard.md b/docs/repository-standard.md index 895ef6a..ecb9af5 100644 --- a/docs/repository-standard.md +++ b/docs/repository-standard.md @@ -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. 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 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.