committed

While auto-generated changelogs aren't the best, they are better than nothing. Too often I've seen projects without a changelog which is especially annoying when dealing with breaking changes. I've been considering switching to a changelog generator, either from Conventional Commits or from a folder of files just to avoid merge conflicts with the CHANGELOG file. If people want enforcement of Conventional Commit, check out https://github.com/crate-ci/committed

At $DAYJOB, we organically switched from not having any formal style to having an internal formal style. People seemed to want the benefits of tooling integration and clearer communication. Right now, we are switching SCM's and are looking at adopting Conventional to replace our internal style. I've already started using Conventional and have really appreciated it. It makes it fast and succinct (remember, line length "requirements" in git) to get the information you need even in one-line logs. Also, it makes CHANGELOG maintenance easier, whether using an automated tool or doing it by-hand. Not happy with the other ones, I've created my own commit style validation tool, committed [0] and have deployed it on my open source projects. Like code style enforcement in CI, I like delegating this to a tool since it makes the requirement very c