keep-a-changelog VS towncrier

A style guide for changelogs, adapted from and a stricter subset of [Keep a Changelog](https://keepachangelog.com/)

not entirely related to your question, but worth a read : https://keepachangelog.com/

A Changelog should be written for each release, conforming to the standard https://keepachangelog.com/

I agree, I used to have a NEWS file in my projects (later a NEWS.md), but as others commented, the signification of the term "changelog" has changed. Sites like https://keepachangelog.com/ really refers to release notes or news.

Overall I like the format and advice from https://keepachangelog.com/

We’ve adopted it at work and it’s nice to have a consistent format that is relatively noise free.

You can read more about it at: https://keepachangelog.com/

# Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ## [0.0.4] - 2014-08-09 ### Added - Better explanation of the difference between the file ("CHANGELOG") and its function "the change log". ### Changed - Refer to a "change log" instead of a "CHANGELOG" throughout the site to differentiate between the file and the purpose of the file — the logging of changes. ### Removed - Remove empty sections from CHANGELOG, they occupy too much space and create too much noise in the file. People will have to assume that the missing sections were intentionally left out because they contained no notable changes. ## [0.0.3] - 2014-08-09 ### Added - "Why should I care?" section mentioning The Changelog podcast. ## [0.0.2] - 2014-07-10 ### Added - Explanation of the recommended reverse chronological release ordering. ## [0.0.1] - 2014-05-31 ### Added - This CHANGELOG file to hopefully serve as an evolving example [Unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.4...HEAD [0.0.4]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.3...v0.0.4 [0.0.3]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.2...v0.0.3 [0.0.2]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.1...v0.0.2 [0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1

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/

Here is an example of another decent one. Not perfect, but it is generated with TownCrier, so it is easy to maintain.

We used to... somewhat attempt manual changelogs. Every time it came to a release the release manager would ask around for what the key changes were, and we usually ended up with only a couple of entries.

Now, we use https://github.com/twisted/towncrier . Every change goes through pull requests, and every PR must have a newsfragment file - and we enforce this with a test that fails if it isn't present (with convenience functions of rewriting the number to match the PR if you name the news file XXX.{category}). If it's not a user-facing change, then we just have a category that is ignored.

On releases (or on individual PRS along the way), the release manager generates the changelog, but also edits them into a relatively coherent style (or rewrites developers news fragments along the way).

Every change has a note written aimed at the user. Every entry in the changelog has a link to the relevant PR or commit. We have much better changelogs now.

Twisted's Town Crier is a generic tool