Commit Message Convention¶

We use Conventional Commits. Commit messages are parsed by our release note generator to produce changelogs automatically, so consistent formatting matters.

Format¶

<type>: <subject>

<body>

<footer>

An optional scope can be added in parentheses: fix(bindings): resolve nullable handling.

Types¶

Type	Description	Release notes category
`break`	Breaking change to the public API	Breaking Changes
`feat`	New feature	Features
`fix`	Bug fix	Fixes
`refactor`	Code change that neither fixes a bug nor adds a feature	Refactoring
`perf`	Performance improvement	Performance
`chore`	Build process, tooling, or maintenance	General Changes
`test`	Adding or updating tests	Tests
`doc`	Documentation only changes	Documentation
`style`	Formatting, whitespace — no code behaviour change	Style Changes
`dep`	Dependency updates	Dependencies
`ci`	CI/CD pipeline changes	General Changes

Note

Dependency bot commits (Renovate, Dependabot) are automatically categorised as dependency updates regardless of prefix.

Subject¶

Use imperative, present tense: "change" not "changed" nor "changes"
Don't capitalise the first letter
No full stop at the end

Body¶

Optional. Use it to explain why the change was made and how it differs from previous behaviour. Same tense rules as the subject.

Use the footer for:

Breaking changes — start with BREAKING CHANGE: followed by a description
Issue references — e.g. Closes #123

Examples¶

feat: add WhenAnyValue overload for six properties

Closes #4200

break: seal ValidationState as record

BREAKING CHANGE: ValidationState is now a sealed record. Subclassing is no longer supported.

chore(deps): update dependency DynamicData to 9.4.31