Skip to content
Sim by rConfig Sim by rConfig rcfg-sim

Commit conventions

rcfg-sim uses Conventional Commits. Consistent commit messages drive the changelog and make the version bump obvious.

Format

Section titled “Format”
<type>[(scope)][!]: <subject>
  • type — one of: feat, fix, refactor, test, docs, chore, perf, build, ci
  • scope — optional, e.g. (sshsrv)
  • ! — append when the change is breaking, and include a BREAKING CHANGE: footer
  • subject — lowercase, imperative mood, no trailing period, under 72 characters

Examples

Section titled “Examples”
feat: add fault injection for slow_response variance
fix(sshsrv): close listener on graceful shutdown to release port
docs: expand the drivers section with a Ciena worked example

A breaking change:

feat!: rename size buckets to clothing-size labels


BREAKING CHANGE: small/medium/large/huge renamed to sm/md/lg/xl.
--distribution strings, manifest size_bucket values, and template
filenames all changed. Users must update --distribution invocations.

Why it matters

Section titled “Why it matters”

The commit type and the !/BREAKING CHANGE marker determine the release bump. Anything that touches the breaking-change surface — CLI flags, model names, metric names/labels, manifest schema, default paths, unit names — is a breaking change and must be flagged. When in doubt, read Scope & versioning before committing.