Document recommended release-trigger split for Clean Commit types

[warengonzaga]

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 Guidance
• Suggested Workflow Split
• Recommended 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:

• new
• update
• remove
• security

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:

• setup
• chore
• test
• docs
• release

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.