Changelog rules

Changelog Rules

The changelog is kept in CHANGELOG.md at the project root. The format is based on Keep a Changelog, and projects using these conventions adhere to Semantic Versioning.

File Structure

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

## [1.2.0] - 2024-03-15

### Added

- Add dark mode support ([#38](https://github.com/owner/repo/issues/38), [#42](https://github.com/owner/repo/pull/42))

### Fixed

- Fix crash on startup ([#40](https://github.com/owner/repo/issues/40), [#43](https://github.com/owner/repo/pull/43))

[Unreleased]: https://github.com/<owner>/<repo>/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/<owner>/<repo>/compare/v1.1.0...v1.2.0
[1.1.0]: https://github.com/<owner>/<repo>/releases/tag/v1.1.0

Changelog-Worthiness

Not every change belongs in a changelog. Changelogs are for humans, not machines.

Skip changes that are purely internal:

• Refactoring with no user-facing impact
• Code formatting, linting, whitespace
• Test additions or modifications (unless they indicate a fixed bug)
• CI/CD configuration
• Developer tooling (linters, editor config)
• Documentation updates (README, comments, docstrings)
• Dependency bumps with no behavior change

Include changes that affect users:

• New features or capabilities
• Changes to existing behavior
• Deprecated or removed functionality
• Bug fixes
• Security patches

Entry Format

• Imperative present tense without trailing periods (e.g., "Add dark mode support")
• One bullet point per distinct change
• Concise but complete. Include enough context that users understand the impact.

User-Centric Writing

Entries describe what changed for the user. Focus on outcomes and impact.

• Lead with a user-visible verb: "Add", "Fix", "Improve", "Allow", "Prevent", "Show", "Check". Avoid developer-centric verbs like "Enforce", "Implement", "Refactor", "Handle", "Register".
• Describe the experience, not the mechanism.
• When a change prevents a problem or protects the user, say what it does for them.

Net Delta from the Last Release

Entries describe the change relative to the last released version.

• Watch for entries that only make sense against an unreleased build, like "no longer does X" or "removed the Y glitch" where X or Y never shipped.
• When finalizing a release, review every entry and rewrite or collapse anything a user of the previous release would not observe.
• Keep one entry per net user-visible change.

PR and Issue References

Reference both the PR and any associated GitHub issue in each entry using inline parenthetical format with linked numbers in ascending order.

- Add dark mode support ([#38](https://github.com/owner/repo/issues/38), [#42](https://github.com/owner/repo/pull/42))

To discover associated issues for a PR, run:

gh pr view <number> --json closingIssuesReferences --jq '.closingIssuesReferences[].number'

• If there is no associated issue, reference only the PR
• If there is no PR (e.g., backfilling from git tags), omit references

Change Types

Standard types in this order when present: Added, Changed, Deprecated, Removed, Fixed, Security. Omit empty sections.

Section Format

• Unreleased section always present at the top
• ISO 8601 dates (YYYY-MM-DD)
• Reverse chronological order (newest first)
• Blank line between each section header and its content
• Version comparison links at the bottom, derived from the repository's remote URL
• Detect whether the project uses v-prefixed tags (e.g., v1.0.0) or bare tags (e.g., 1.0.0) and match that convention in comparison links