Skip to content

Tracking notable behavior changes in the changelog #7354

@GeigerJ2

Description

@GeigerJ2

We've been going back and forth on this (in #7319 (comment)), so here's a summary of the two approaches. The auto-generated commit list stays as the baseline in both cases; the question is how we capture the curated prose for notable behavior changes (the kind that ended up in v2.8's "Behavior changes" section).

A: Git trailer (Behavior-Change: in the commit message)

  • ✅ Travels with the commit through rebase and cherry-pick, so patch releases get it for free
  • ✅ No merge conflicts
  • ✅ Extractable in one shell command (git log --pretty=format:'%(trailers:key=Behavior-Change,...)')
  • ❌ Developer-facing artifact (commit message), not user-facing documentation
  • ❌ Easy to miss during review (no file-level diff to prompt reviewers)
  • ❌ Hard to enforce without custom tooling
  • ❌ Higher barrier for external contributors unfamiliar with trailer conventions

B: Continuous CHANGELOG.md ("Unreleased" section, updated per PR)

  • ✅ User-facing documentation, written where users actually look
  • ✅ Visible in the PR diff, so reviewers naturally ask "does this need an entry?"
  • ✅ Lower barrier for contributors (just add a line to a familiar file)
  • ✅ Already a common convention in many projects
  • ❌ Doesn't travel with cherry-picks; needs manual re-edit on release branches
  • ❌ Potential merge conflicts (low risk with our team size)

Feel free to vote with emoji reactions, so we can already get everybodies opinion:

  • 🚀 for A (git trailer)
  • 👍 for B (continuous CHANGELOG.md)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions