Summary
Clean Commit already defines the 9 official commit types clearly, including breaking change support with !. What is still missing is guidance for teams that want to use Clean Commit as the basis for automated release workflows.
A useful addition to the docs would be a recommended split between:
- commit types that should trigger releases
- commit types that should not trigger releases but are still changelog-worthy
This would help projects use Clean Commit consistently for release automation without inventing their own interpretation from scratch.
Why This Matters
Many projects use commit conventions for more than commit history readability. They also use them for:
- semantic version bump detection
- release automation
- changelog generation
- unreleased changelog staging
- workflow triggers
Right now, Clean Commit explains the format and the 9 types well, but it does not explicitly document how a project might classify those types for release-trigger behavior.
That leaves room for inconsistent implementations across projects.
Proposed Documentation Improvement
Add a small section to the docs such as:
Release Automation GuidanceSuggested Workflow SplitRecommended Release Trigger Mapping
The section would not redefine Clean Commit itself. It would simply provide a recommended reference model for teams building release workflows.
Suggested Reference Split
Release-triggering commit types
These are the types that most naturally represent shipped code or behavior changes:
newupdateremovesecurity
Breaking variants of those types should be treated as major-release signals:
new!update!remove!security!
Non-release-triggering commit types
These are valid and useful commit types, but they do not necessarily need to create a release on their own:
setupchoretestdocsrelease
Why This Split Makes Sense
new, update, remove, and security most directly map to shipped functionality, behavior, compatibility, or security changes.setup, chore, test, and docs are often important enough to document, but they do not always justify cutting a new version.release is typically a bookkeeping or versioning action, not the cause of the release itself.
Suggested Note for Documentation
It may help to explicitly state that this is only a recommended automation model, not a mandatory part of the Clean Commit specification.
Something like:
Clean Commit defines commit message structure and type meaning. Projects may optionally use a release-trigger split for automation. A common recommendation is to let new, update, remove, and security drive releases, while treating setup, chore, test, docs, and release as non-release-triggering but still valid commit types.
Optional Follow-Up Documentation
It may also be useful to include one short example showing how projects could use non-release-triggering types in changelog workflows, for example:
- visible in an
[Unreleased] section
- included in changelog output
- not used to bump versions by themselves
Expected Benefit
This would give teams a stable reference when using Clean Commit for:
- GitHub Actions release flows
- semantic release tooling
- custom changelog generators
- internal release policies
It would also reduce ambiguity across projects that want to adopt Clean Commit as both a commit standard and an automation input.
Summary
Clean Commit already defines the 9 official commit types clearly, including breaking change support with
!. What is still missing is guidance for teams that want to use Clean Commit as the basis for automated release workflows.A useful addition to the docs would be a recommended split between:
This would help projects use Clean Commit consistently for release automation without inventing their own interpretation from scratch.
Why This Matters
Many projects use commit conventions for more than commit history readability. They also use them for:
Right now, Clean Commit explains the format and the 9 types well, but it does not explicitly document how a project might classify those types for release-trigger behavior.
That leaves room for inconsistent implementations across projects.
Proposed Documentation Improvement
Add a small section to the docs such as:
Release Automation GuidanceSuggested Workflow SplitRecommended Release Trigger MappingThe section would not redefine Clean Commit itself. It would simply provide a recommended reference model for teams building release workflows.
Suggested Reference Split
Release-triggering commit types
These are the types that most naturally represent shipped code or behavior changes:
newupdateremovesecurityBreaking variants of those types should be treated as major-release signals:
new!update!remove!security!Non-release-triggering commit types
These are valid and useful commit types, but they do not necessarily need to create a release on their own:
setupchoretestdocsreleaseWhy This Split Makes Sense
new,update,remove, andsecuritymost directly map to shipped functionality, behavior, compatibility, or security changes.setup,chore,test, anddocsare often important enough to document, but they do not always justify cutting a new version.releaseis typically a bookkeeping or versioning action, not the cause of the release itself.Suggested Note for Documentation
It may help to explicitly state that this is only a recommended automation model, not a mandatory part of the Clean Commit specification.
Something like:
Optional Follow-Up Documentation
It may also be useful to include one short example showing how projects could use non-release-triggering types in changelog workflows, for example:
[Unreleased]sectionExpected Benefit
This would give teams a stable reference when using Clean Commit for:
It would also reduce ambiguity across projects that want to adopt Clean Commit as both a commit standard and an automation input.