fix(release): the changelog listed unreleased work twice, and a setting was undocumented - #67
Merged
Merged
Conversation
…ng was undocumented Both found by running the thing for the first time rather than by reading it. THE DUPLICATE LIST. CHANGELOG.md carried a hand-written "Unreleased -- not yet cut" section, written before there was anything generating one. release-please inserts its section below the preamble, so the first proposal produced a file with the same seventeen features under "Unreleased" and again under "[0.5.0]". Only one of the two is kept current, and it is not the hand-written one. It is removed, and the preamble now says where unreleased work is: in the open proposal, which is rewritten on every push to main. THE SETTING. The first run failed after doing everything else correctly -- 120 commits parsed, bump computed, branch created, commit written -- and stopped at "GitHub Actions is not permitted to create or approve pull requests". That is a repository setting, off by default, and nothing in the repository records that the release depends on it. The workflow, the config and the manifest can all be right while no release happens, and the only symptom is a failed run. It is documented with both routes to it and with what the checkbox actually grants. The approving half gates nothing today: main has no branch protection and no rulesets, so there is no required review for a workflow's approval to satisfy. Noted as the thing that changes if protection is added. default_workflow_permissions stays read. The workflow declares the write scopes it needs in its own permissions block, which is narrower than raising the default for every workflow in the repository.
rexionmars
added a commit
that referenced
this pull request
Aug 31, 2026
Each of these appeared once for the commit that made the change and once for the merge commit of the pull request carrying it. release-please reads both, and attributes the PR's title to the merge, so any PR holding a single conventional commit is counted twice. All four here are that shape: #54, #56, #60 and #67. The merge-commit line is the one dropped. Both point at the same work, and the original commit is the more precise of the two. This is the same symptom #67 fixed and a different cause. That one removed a hand-written Unreleased section; this is structural, and returns on any release where a single-commit PR was merged rather than squashed. Squash merging is what removes it at the source.
rexionmars
added a commit
that referenced
this pull request
Aug 31, 2026
Each appeared once for the commit that made the change and once for the merge commit of the pull request carrying it -- release-please reads both, and gives the merge the PR's title, so a PR holding a single conventional commit is counted twice. All four are that shape: #54, #56, #60 and #67. The merge-commit line is dropped; both point at the same work and the original commit is the more precise of the two. DONE BY HAND FOR THE LAST TIME. Merge commits are now disabled on the repository, so squash and rebase are the only ways a pull request can land and neither creates a second conventional commit. That does not reach these four: the merges that produced them are already in the history and stay there, so they would return in every regeneration of this proposal. They are removed here because this is the release that carries them.
rexionmars
added a commit
that referenced
this pull request
Aug 31, 2026
* chore(main): release 0.5.0 * chore(release): drop the four entries a merge commit listed twice Each appeared once for the commit that made the change and once for the merge commit of the pull request carrying it -- release-please reads both, and gives the merge the PR's title, so a PR holding a single conventional commit is counted twice. All four are that shape: #54, #56, #60 and #67. The merge-commit line is dropped; both point at the same work and the original commit is the more precise of the two. DONE BY HAND FOR THE LAST TIME. Merge commits are now disabled on the repository, so squash and rebase are the only ways a pull request can land and neither creates a second conventional commit. That does not reach these four: the merges that produced them are already in the history and stay there, so they would return in every regeneration of this proposal. They are removed here because this is the release that carries them. * docs(release): what 0.5.0 changed, for the reader rather than the repository Seven items out of a hundred, and the cut is the work. The changelog beside this carries 42 features and 58 fixes; What's New answers a different question, asked by someone who has just updated and wants to know what is different in front of them. A fix is not that -- it says something was broken -- so the fixes are out by rule rather than by judgement, and the judgement is which of the 42 a reader would notice. The two voices are not a transformation of each other. `**energy:** the run reads in a column of its own` is a commit subject: a scope, a hash, and the assumption that the reader knows the code. The entry it becomes has to say where the thing was before and why moving it mattered, which the changelog never recorded. That is why this is not generated. IT IS IN THE RELEASE PROPOSAL, not on main, and that is the ordering the version check demands. main still says 0.4.0 in version.go, and an entry for 0.5.0 there would sit ahead of the authority and fail check:version until the proposal merged. Here the bump and the notes land together and neither branch is ever inconsistent. The title names the release by what it is: work now belongs to the ground it was made over, and the ground is drawn on a planet. Draugen is the still that names it -- see brand.ts and the manifest in splashBackground.ts. --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: rexionmars <opensource.leonardi@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two defects the first
release-pleaserun exposed, neither visible by reading the files.The duplicate list
CHANGELOG.mdcarried a hand-written## Unreleased — not yet cutsection, written before anything generated one. release-please inserts its section below the preamble, so the first proposal produced a file with the same seventeen features under Unreleased and again under [0.5.0].Only one of the two is kept current, and it is not the hand-written one. It is removed; the preamble now says where unreleased work lives — in the open proposal, rewritten on every push to
main.The undocumented setting
The first run failed after doing everything else correctly: 120 commits parsed, bump computed (
0.5.0, correct), branch created, commit written. It stopped at:That is a repository setting, off by default, and nothing in the repository recorded that releasing depends on it. The workflow, the config and the manifest can all be right while no release happens, and the only symptom is a failed run.
docs/RELEASING.mdnow carries both routes to it and what the checkbox actually grants. The approving half gates nothing today —mainhas no branch protection and no rulesets, so there is no required review for a workflow's approval to satisfy. That is noted as the thing which changes if protection is added.default_workflow_permissionsstaysread: the workflow declares the write scopes it needs in its ownpermissions:block, which is narrower than raising the default for every workflow in the repository.Testing
Documentation and a changelog section only; no code paths change.
npm run check:versionis unaffected and clean.The setting itself is not applied by this PR — it is a repository setting, not a file. Until it is turned on,
release-please.ymlwill keep failing at the same step, having correctly built the proposal branch each time.Checklist