Do you have a rule of thumb for this? Does anyone on your team own this decision, or does it fall to whoever writes the release?
Ask HN: How do you decide what goes in a changelog vs. internal notes?
1–5 of 5 posts
Re: Ask HN: How do you decide what goes in a changelog vs. internal notes?
#2changelogs are for consumers, internal notes are for the team.
Ideally, nobody should be making this decision manually at release time. If you use semantic versioning and Conventional Commits, you can completely automate changelogs generation. This shifts the responsibility to individual developers to write properly scoped commit messages
Re: Ask HN: How do you decide what goes in a changelog vs. internal notes?
#3changelogs are for consumers, internal notes are for the team. Ideally, nobody should be making this decision manually at release time. If you use semantic versioning and Conventional Commits, you can completely automate changelogs generation. This shifts the responsibility to individual developers to write properly scoped commit messages
[flagged]
Re: Ask HN: How do you decide what goes in a changelog vs. internal notes?
#4Is this a real question or an ad for R******H**?
Re: Ask HN: How do you decide what goes in a changelog vs. internal notes?
#5changelogs are for consumers, internal notes are for the team. Ideally, nobody should be making this decision manually at release time. If you use semantic versioning and Conventional Commits, you can completely automate changelogs generation. This shifts the responsibility to individual developers to write properly scoped commit messages
exactly. a good commit message apart from keeping track of what shipped, also lets u automate the changelog/release note generation. i built commitposts.com around this idea.