[ajanuary]

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.