As of v0.3.0 (c73dc6c).
Summary
cargo-dist generates GitHub release pages, but user-facing surface changes are already accumulating without a reviewable history: new config keys per release, protocol VERSION bumps (now at 7), and default-behavior changes (e.g. the git status display controls in v0.3.0). A prompt is the most-seen UI a user has; "what changes when I upgrade" deserves a better answer than a commit list.
Proposed fix
- Add
CHANGELOG.md (Keep a Changelog format), seeded retroactively from the existing history (v0.1.0 → v0.3.0; the release PRs #6, #8, #17, #23 and the feature PRs between them make this reconstructible).
- Decide the maintenance mechanism: hand-written per release PR (low tooling, matches the current release flow) or git-cliff generation from conventional commits (the repo already uses conventional commit prefixes consistently).
- Wire it into the release checklist in CONTRIBUTING.md so version-bump PRs must touch it.
Split from #30: this is a release-process decision, not a Cargo.toml edit.
🤖 Generated with Claude Code — Claude Fable 5
As of v0.3.0 (c73dc6c).
Summary
cargo-dist generates GitHub release pages, but user-facing surface changes are already accumulating without a reviewable history: new config keys per release, protocol VERSION bumps (now at 7), and default-behavior changes (e.g. the git status display controls in v0.3.0). A prompt is the most-seen UI a user has; "what changes when I upgrade" deserves a better answer than a commit list.
Proposed fix
CHANGELOG.md(Keep a Changelog format), seeded retroactively from the existing history (v0.1.0 → v0.3.0; the release PRs#6,#8,#17,#23and the feature PRs between them make this reconstructible).Split from #30: this is a release-process decision, not a
Cargo.tomledit.🤖 Generated with Claude Code — Claude Fable 5