| name | bondery-changelog |
| description | Bondery product changelog format, change categories, commit prefixes, calendar versioning, and release-note workflow. Use when editing docs/changelog/unreleased.mdx, documenting a user-visible or operationally notable change, preparing a release, choosing a conventional commit prefix, recording dependency updates, or drafting release communications.
|
| metadata | {"version":"1.0.0","namespace":"bondery"} |
Bondery Changelog
When to use
- Adding a notable change under
Unreleased
- Turning unreleased entries into a dated version section
- Choosing a changelog category or commit prefix
- Preparing monthly, patch, hotfix, dependency, or security release notes
- Using changelog entries as source material for a release blog post
Non-negotiables
- One product changelog —
docs/changelog.mdx composes version partials under docs/changelog/ and is the page published by Fumadocs. Edit docs/changelog/unreleased.mdx for in-flight work.
- Write for users and operators — explain the outcome and affected area, not implementation trivia or commit history.
- Curate manually — commit prefixes help classify changes, but no script generates the product changelog.
- Keep
Unreleased at the top — collect notable work there until a release is cut.
- Newest release first — use
## [X.Y.Z] - DD.MM.YYYY and Bondery's calendar version scheme.
- Call out breaking changes — migrations, environment/config changes, port changes, and temporary client/server incompatibilities need a
Breaking section with an upgrade path.
- Keep ownership separate — deployment sequencing stays in the release workflow; API compatibility rules stay in
bondery-api.
Routine internal refactors, test-only changes, and formatting do not need product changelog entries unless they materially affect contributors, self-hosters, release safety, or user behavior.
Decision tree
Full local-reference index: references/README.md.
Changelog checklist (before handoff)
