3 ms·

I don't really like writing the change log automatically from commits. I think those both have a slightly different audience and thus need different wording. I

I don't really like writing the change log automatically from commits. I think those both have a slightly different audience and thus need different wording. I know the frustration of merge conflicts on the change log file. Right now, I'm creating change logs by hand which is time consuming to do on release time. I'm considering switching to using towncrier or something similar, where you have a changes dir with one file per change for creating change logs --> https://towncrier.readthedocs.io/ https://towncrier.readthedocs.io/

ajanuary 2y ago
The towncrier approach is similar to what we do at work. We have the addition that the individual changelog files say their scope (major, minor, or patch), and we use that to automatically compute the next version number. version.txt 1.0.0 CHANGELOG # 1.0.0 * Initial release changelogs/add-foobar-api.md minor: Add a new API call `foobar` changelogs/improve-baz-perf.md patch: Improve the performance of the `baz` API call In the changelog compilation step it works out that the largest scope is minor, so the version of the next release is bumped from 1.0.0 to 1.1.0, and you end up with: version.txt 1.1.0 CHANGELOG # 1.1.0 * Add a new API call `foobar` * Improve the performance of the `baz` API call # 1.0.0 * Initial release It works great, especially for large teams. You don't end up with lots of merge conflicts on the CHANGELOG file. The people writing the change get to describe the scope of the change (and that can be reviewed in the PR), rather than the person doing the release having to guess from the descriptions. Developers never have to worry about whether someone else has already bumped the version number or not.