keep-a-changelog VS release-please

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

Using Conventional Commits ⭐ as a standard for your commit messages, makes Semantic Versioning 🔖 as easy as can be, with tools like Conventional Changelog 📄 Standard Version 🔖 and Semantic Release 📦🚀

Conventional Commits

We've covered everything about writing well-formatted and structured code without worrying too much about it anymore. The only part we haven't explored yet is linting commit messages. Commitlint will help us here. It allows you to configure any rules you want for the commit message, but we're going to use the Conventional Commits specification, one of the most popular conventions you'll find.

Commit Management with Conventional Commits: The Conventional Commits methodology is adopted to maintain a clear and structured record of changes with the help of commitlint.

Validate if the commit titles adhere to the Conventional Commits Specification in Merge requests.

Check out https://www.conventionalcommits.org

FYI there is already a popular tool that does just this with a very similar name: https://github.com/googleapis/release-please

The feature commit should have a clear defined message - Don't re-invent here - There exists a fairly used and accepted convention called Conventional Commits, so we are going to use that.