docs: hidden commit types ship no release; refactor is one of them - #71
Conversation
The type table said refactor produced a patch bump — release-please hides it. And it said ci produced no bump, which #69 then ignored: the PR lint, a change every adopter sees, shipped as ci: and release-please skipped it. Both skills now say what to do when a release-worthy change only fits a hidden type: Release-As in the PR body. Closes #70 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d730499fbd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| all — it is a hidden type. A change users will notice that only fits a hidden | ||
| type (a new CI gate under `ci`, a behaviour-changing `refactor`) still has to | ||
| ship: put a `Release-As: X.Y.Z` footer in the PR body (the body becomes the |
There was a problem hiding this comment.
A user-visible behavior change cannot be a refactor under this table's own definition of “no behavior change”; it should be classified as feat, fix, or perf. Keeping it hidden and adding Release-As may cut a tag, but the change remains excluded from the generated changelog, so this example teaches maintainers to publish an undocumented behavioral change.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 5155034: the refactor example is gone; the text now says a user-visible change is usually a feat or fix, and that a hidden type also keeps it out of the changelog — Release-As is only for a genuinely hidden type that still needs a tag.
|
|
||
| ## Pitfalls | ||
|
|
||
| - Shipping a release-worthy change under a hidden type (`ci`, `chore`, `docs`, `refactor`, `test`) and waiting for a release PR that never comes — release-please logs `No user facing commits found … skipping`. Either the type was wrong (`feat`/`fix`), or add `Release-As: X.Y.Z` to the PR body so the squash commit carries it (see `skills/branch-and-commit` rule 3). |
There was a problem hiding this comment.
For a correctly classified hidden-type change, this instruction requires the maintainer to choose an exact X.Y.Z, while rule 2 still states without exception that the version is derived rather than chosen. Define how the override's SemVer level is selected and identify it as an explicit exception; otherwise agents following the two normative instructions have no consistent way to determine the footer value.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 5155034: rule 2 names the exception and fixes the level — Release-As is always the current version plus one patch; wanting more means the type was wrong. The pitfall and branch-and-commit rule 3 point at it.
🤖 I have created a release *beep* *boop* --- ## [0.5.2](v0.5.1...v0.5.2) (2026-09-16) ### Documentation * hidden commit types ship no release; refactor is one of them ([#71](#71)) ([819ce60](819ce60)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…viour-changing refactor is not a hidden type (#74) <!-- markdownlint-disable-next-line MD041 --> ## Summary Re-lands commit `5155034`, the answer to Codex's two P2 findings on #71, which was pushed after #71 had already been squash-merged and its branch deleted, so it never reached `main`. Cherry-picked verbatim (`-x`). - `skills/branch-and-commit` rule 3: drop "a behaviour-changing `refactor`" as an example of a hidden-type change that ships via `Release-As` — a refactor that changes behaviour is a `fix` or a `feat`. Say first that a change users notice is usually not a hidden type at all, and bound the footer: `X.Y.Z` is the current version plus one patch, pointing at release-management rule 2. - `skills/release-management` rule 2 ("version bump is derived, not chosen"): state the one exception — a genuinely hidden-type change that adopters must pick up — with the same patch-only bound, and note that a hidden type also keeps the change out of the changelog. The pitfall now refers to rule 2 instead of restating the recipe. Docs only, hidden type, no release. ## Related issue Closes #73 ## Validation Pick validation depth by blast radius. A level that applies but could not run becomes a `RISK:` line below. See AGENTS.md for the validation ladder. - [x] L0 static — `make lint` - [x] L1 unit — `make test` (placeholder target; `make check` runs the node tests, both green) - [ ] L2 integration — not applicable, prose only - [ ] L3 e2e / preview — not applicable ## Risk / rollback ```text Rollback: revert this PR; two skill files change, nothing executes them ``` ## Checklist Before merging: - [x] Conventional Commit PR title (`<type>: <description>`) - [x] Linked issue using "Closes #N" - [x] No secrets, no `*.local.md` files committed - [x] Documentation updated where affected --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
1 participant
Summary
skills/branch-and-commit's type table saidrefactorproduces a patch bump — release-please hides it, no release. It also saidciproduces no bump, which #69 ignored: the PR lint shipped asci:and release-please skipped it (No user facing commits found). Both skills now say what to do when a release-worthy change only fits a hidden type. This PR is the recipe in use.Related issue
Closes #70
Validation
make verifygreenchore: release 0.5.2(the footer below)Risk / rollback
Checklist
*.local.mdfiles committedRelease-As: 0.5.2