When publishing a package for use by programmers, automated changelog generation is very beneficial. In this blog post, I explore how to do it in a simple way that works everywhere.
When publishing a package for use by programmers, automated changelog generation is very beneficial. In this blog post, I explore how to do it in a simple way that works everywhere.
Oh, nice.
I’m always looking for another ChangeLog tool.
That said, I never leave my ChamgeLogs up to automation.
My git logs are open to my users for full details, but my ChangeLogs are how I communicate which changes my users probably need to be aware of.
So far, this hasn’t yielded well to automation. But my team is still considering standardizing our commit log messages enough to allow it someday.
Thanks for your feedback!
Some thoughts:
cliff.toml(generated withgit-cliff --init) to ignore any commits that aren’t interesting to your usersI should probably add those to the blog.
But yeah, I get preferring to write manual tailored changelogs. Personally I am just a little neurotic about single source of truth and a huge Git nerd. And I know that at least in this job, my users are neurotic enough to prefer completeness.
We do always squash merge, which certainly helps.
I was not aware of
cliff.toml. Thank you!