Changelog
Every board/package gets aCHANGELOG.md at its root (pcb new creates one). Parsed by pcb publish for release notes and by the build system for CLI display, so format matters.
Format
Follow Keep a Changelog 1.1.0:Rules
[Unreleased]first. Add entries here as you work.pcb publishmoves them into a versioned section with today’s date.- One entry per user-visible change. Internal refactors with no behavior change don’t need entries.
- Four categories only.
Added,Changed,Fixed,Removed. Omit empty ones. - Newest version first. Reverse chronological order.
- Write for the upgrader. Lead with what changed, not why. Note if action is needed.
Writing Entries
Each entry is- followed by a concise description. Use backticks for identifiers.
Good:
Versioning
Semantic Versioning:- Patch (0.3.1 → 0.3.2): Metadata only — docs, property typos, manufacturer aliases. No connectivity or behavior changes.
- Minor (0.3.x → 0.4.0): New non-breaking functionality — optional pins, new config options, additional footprint variants.
- Major (0.x → 1.0): Breaking changes requiring design updates — changed pin definitions, restructured interfaces, removed features.
pcb publish bumps minor (0.3.2 → 0.4.0) since minor versions are treated as potentially breaking.
Tooling
pcb publish— reads[Unreleased]as the release body for the annotated git tag.- Build-time extraction — CLI parses changelog at compile time for
pcb doc --changelog. Expects## [...]version headers and### Categorysubsections.
## [X.Y.Z] - YYYY-MM-DD for versions and ## [Unreleased] for the working section.