3 ms·

These "changelog generators" look to me like barking at the wrong tree, automation for the sake of automation, and attempt to skip the "boring" work of communic

by ilammy 4y ago

These "changelog generators" look to me like barking at the wrong tree, automation for the sake of automation, and attempt to skip the "boring" work of communicating changes by replacing it with "interesting" work of massaging git history, inventing microformats, etc. Why bother with separate changelogs at all then when you can see changes in `git log`. Just write good commit messages! /s

emacs28 4y ago
Well rather than manually enter the bug fixes/features introduced in each release on the GitHub releases, you can just paste a link to the automatically generated changelog. This is less error prone and isn't meant to replace writing good commit messages.
- est31 4y ago
  Yes, but you might present some feature differently internally compared to your users. E.g. "Update libfoo" is a totally fine commit message, as you can just inspect the diff to see the version change, but in the changelog, I'd prefer "Update libfoo to 0.3" because dependency versions are something that's exposed to users of your component. Conversely, you might have a bunch of refactoring commits that each are important as their own unit but your changelog is maybe only interested in a summary. Personally I don't see much value in these half-automatted changelogs over just giving git history. It also raises the bar for contributions because contributors have to figure out a non standard commit message format.
  - emacs28 4y ago
    These are good points. Just to clarify, I can't speak for semantic release, but the github-changelog-generator I'm talking about will only add PRs (and issues if you want) to the changelog, not commits (so no non-standard commit message format needed). So you can put anything worth mentioning in a changelog into a PR, and it distinguishes between bug fix vs feature based on the tags added to the PR.

3 ms·

These "changelog generators" look to me like barking at the wrong tree, automation for the sake of automation, and attempt to skip the "boring" work of communic

by ilammy 4y ago

emacs28 4y ago
Well rather than manually enter the bug fixes/features introduced in each release on the GitHub releases, you can just paste a link to the automatically generated changelog. This is less error prone and isn't meant to replace writing good commit messages.
- est31 4y ago
  Yes, but you might present some feature differently internally compared to your users. E.g. "Update libfoo" is a totally fine commit message, as you can just inspect the diff to see the version change, but in the changelog, I'd prefer "Update libfoo to 0.3" because dependency versions are something that's exposed to users of your component. Conversely, you might have a bunch of refactoring commits that each are important as their own unit but your changelog is maybe only interested in a summary. Personally I don't see much value in these half-automatted changelogs over just giving git history. It also raises the bar for contributions because contributors have to figure out a non standard commit message format.
  - emacs28 4y ago
    These are good points. Just to clarify, I can't speak for semantic release, but the github-changelog-generator I'm talking about will only add PRs (and issues if you want) to the changelog, not commits (so no non-standard commit message format needed). So you can put anything worth mentioning in a changelog into a PR, and it distinguishes between bug fix vs feature based on the tags added to the PR.