At Mozilla we share a lot of open source libraries. When you’re using someone else’s library, you might find that an upgrade breaks something in your application — but why? Glancing at the library’s changelog can help. However, manually maintaining a changelog when building features for a library can be a challenge.<\/p>\n
We’ve been experimenting with auto-generating a changelog from commit history itself and so far it makes changelogs easy and painless. Here’s how to set it up. These tools require NodeJS<\/a> so it’s best suited for JavaScript libraries.<\/p>\n First, you need to write commit messages in a way that allows you to extract metadata for a changelog. We use the Angular conventions<\/a> which specify simple prefixes like Here’s an example of a bug fix:<\/p>\n The nice thing about this convention is that tools such as Greenkeeper<\/a>, which sends pull requests for dependency updates, already support it.<\/p>\n The first problem with this is a social one; all your contributors need to follow the convention. We chose to solve this with automation by making the tests fail if they don’t follow the conventions \ud83d\ude42 It’s also documented in our There was one gotcha in that TravisCI<\/a> only does a shallow clone which doesn’t create a master branch. This will probably be fixed in the linter soon<\/a> but until then we had to add this to our feat:<\/code> for new features and fix:<\/code> for bug fixes. Here’s an example of a commit message that adds a new feature:<\/p>\nfeat: Added a `--timeout` option to the `run` command<\/code><\/p>\nfix: Fixed `TypeError: runner is undefined` in the `run` command<\/code><\/p>\nCONTRIBUTING.md<\/code> file. We use the conventional-changelog-lint<\/a> command as part of our continuous integration to trigger a test failure:<\/p>\nconventional-changelog-lint --from master<\/code><\/p>\n.travis.yml<\/code>:<\/p>\n