Package
Which package does this affect? [x] cli [ ] schema [x] docs [ ] ci
Problem / Motivation
src/conventional_commits.rs parses standard type(scope)!: subject and BREAKING CHANGE: footer correctly, but real-world variants are silently dropped:
breaking-change: (lowercase, hyphen)BREAKING-CHANGE: (uppercase, hyphen)- Multi-paragraph footers
! placed inside scope: feat(api!): ...
High impact: a misclassified breaking change skips the major bump, producing a quietly wrong release.
Proposed solution
Acceptance criteria
- Fixtures under
tests/fixtures/conventional_commits/ covering each variant above.
- Parser detects every variant as a breaking change.
- Documented in the docs site under "conventional commits parsing rules".
- A test asserts that the parser is strict on intentionally wrong shapes (e.g.
Breaking change: without colon-space rules) — i.e. we don't go full Postel-permissive.
Alternatives considered
None considered explicitly — this is the natural shape.
Additional context
Severity: P2
Category: cli/parsing
Kit / UI candidate: No.
Package
Which package does this affect? [x] cli [ ] schema [x] docs [ ] ci
Problem / Motivation
src/conventional_commits.rsparses standardtype(scope)!: subjectandBREAKING CHANGE:footer correctly, but real-world variants are silently dropped:breaking-change:(lowercase, hyphen)BREAKING-CHANGE:(uppercase, hyphen)!placed inside scope:feat(api!): ...High impact: a misclassified breaking change skips the major bump, producing a quietly wrong release.
Proposed solution
Acceptance criteria
tests/fixtures/conventional_commits/covering each variant above.Breaking change:without colon-space rules) — i.e. we don't go full Postel-permissive.Alternatives considered
None considered explicitly — this is the natural shape.
Additional context
Severity: P2
Category: cli/parsing
Kit / UI candidate: No.