Skip to content

ci(release): release refactor and revert commits as patches - #28

Merged
pbennett merged 1 commit into
mainfrom
ci/refactor-release-rule
Aug 28, 2026
Merged

ci(release): release refactor and revert commits as patches#28
pbennett merged 1 commit into
mainfrom
ci/refactor-release-rule

Conversation

@pbennett

Copy link
Copy Markdown
Contributor

#27 merged as refactor(api): and published nothing:

[@semantic-release/commit-analyzer] Analysis of 2 commits complete: no release
There are no relevant changes, so no new version is released.

The Angular preset ships releaseRules for feat, fix, perf and breaking changes only. refactor is not among them, so the regenerated OpenAPI client — and the dropped @hey-api/client-fetch runtime dependency — has been sitting on main while npm still serves the old client in 2.0.0.

The gap was already visible in the config

release-notes-generator is configured with a Code Refactoring section. Under stock rules that section can only ever appear riding along with someone else's feat or fix — a refactor-only change can never cut the release that would display it.

The change

refactor and revert become patch via releaseRules on the commit-analyzer. These are additive: the preset's own rules still apply as the fallback, so feat, fix, perf and BREAKING CHANGE are untouched.

Verified by running analyzeCommits with the real .releaserc.js options against the commits since v2.0.0:

options: {"preset":"angular","releaseRules":[{"type":"refactor","release":"patch"},
                                             {"type":"revert","release":"patch"}]}
commits since v2.0.0:
  - refactor(api): regenerate the OpenAPI client on openapi-ts 0.99 (#27)
  - chore(deps): clear the open Dependabot advisories (#26)
release type: patch

Same input under stock rules is what the release job already reported: no release.

After merge

This is a ci: commit, so it bumps nothing itself — but merging re-runs the analysis over everything since v2.0.0, so #27 then publishes as 2.0.1, which is the point.

Docs

PUBLISHING.md and CONTRIBUTING.md both stated the refactor → patch rule as though it were stock behaviour. That was wrong when written; it becomes true with this commit, and both now name it as a local override rather than presenting it as the Angular default.

#27 merged as `refactor(api):` and published nothing. The Angular preset
ships releaseRules for feat, fix, perf and breaking changes only, so
commit-analyzer returned "no release" and the regenerated OpenAPI client has
been sitting on main while npm still serves the old one in 2.0.0.

The gap was already visible in the config: release-notes-generator lists a
"Code Refactoring" section, which under stock rules can only ever appear
riding along with someone else's feat or fix, never on its own.

Adds refactor and revert as patch through releaseRules on the
commit-analyzer. They are additive — the preset's own rules still apply as
the fallback — and verified against the commits since v2.0.0, which now
analyze as patch rather than none. Merging this therefore also publishes
2.0.1.

Corrects both docs, which stated the refactor rule as though it were stock,
and now name it as a local override.
@pbennett
pbennett merged commit f555e51 into main Aug 28, 2026
1 check passed
@pbennett
pbennett deleted the ci/refactor-release-rule branch August 28, 2026 05:39
@txnlab-release-bot

Copy link
Copy Markdown
Contributor

🎉 This PR is included in version 2.0.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant