olivierlacan

keep-a-changelog

Haml2015–2026

olivierlacan / keep-a-changelog

keep-a-changelog

If you build software, keep a changelog.

Productivity Developer Tools

Explore on GitHub Read Hacker News discussions

3Distinct people

9Mentions

0Explicit recommenders

6.8KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

If you build software, keep a changelog.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year9 dated mentions

Observed mentions: 2015-02-16 13:00:18 UTC to 2026-06-05 18:47:42 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	3	3
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	2	2
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	3	3
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	0	0
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1

What Hacker News says

9 sources

olivierlacan·Jun 5, 2026

Keep a Changelog[0] maintainer here, weirdly seeing this while deep into work on way overdue 2.0 "release"[1], which should be out very soon. I've had to contend with Conventional Commits both in the OSS world and at work as it proliferated from what seemed to me like robotic adoption by folks who were even loosely associated with the Angular ecosystem (remember that?). I've always had a stance with KAC that folks trying to automate changelog creation (prior to LLM rise, mind you) were focusing on the wrong thing. I still think there's a fundamental difference in focus between what you write in a git commit and what you present in a changelog. I know there are fundamental philosophical differences for folks who were used to HISTORY vs. NEWS vs. CHANGELOG but with the growing adoption of KAC-like CHANGELOG.md files and Release Notes (often

Read the rest

not synonymous) I think we're thankfully past the weird era were maintainers dumped raw git log ranges between two tags and called that a changelog. I'm sure some still do it. But that's what Conventional Commits tries to replicate. What's really odd to me is that this assumes (broadly) that every single commit in a repository is relevant to the eventual version release changelog (or release notes). Even if you assume some CC types get filtered and deprioritized from generated changelogs by some tools, it's still a huge miss on what communicating about a release typically means: these change likely matter to you as a package dependent or direct user, while others were omitted for good reason. I'm trying to articulate that much more clearly in KAC 2.0 because there's a fundamental paradigm shift when a robot can now analyze recent work (yours or theirs) and craft changelog entries that appropriately shift the audience perspective from "git message for me/us in the future to understand this change" to "changelog entry for you/them to know what this group of changes means". [0]: https://keepachangelog.com [1]: https://github.com/olivierlacan/keep-a-changelog/pull/600 if anyone's curious and wants to get involved

In Conventional Commits encourages focus on the wrong things

olivierlacan·Jul 28, 2018

People have created million and a half tools to tackle this problem. Just look at the issues and you'll find a ton: https://github.com/olivierlacan/keep-a-changelog/issues?utf8... I've tried to refrain from endorsing tools because I feel like they risk making it easy to avoid doing what I actually encourage: curating the notable changes for a release with your mushy human brain for other mushy human brains. I know it's hard, but perhaps it's a good constraint. The idea that you will have the forethought of knowing when writing a commit that it'll be one of the notable entries in your future changelog seems a bit far-fetched to me. And as I tried to explain, the purpose of a commit is not the same as the purpose of a changelog entry, so there's definitely tension in the re-use of copy there. I get the instinct to automate everything. I'm j

Read the rest

ust not sure this is something that should be automated. Now, an assistive tool to help maintainers review commits for missing notable changes within a changelog, that's something I could get behind.

In Keep a Changelog

olivierlacan·Jul 28, 2018

Since, as okket mentioned, Keep a Changelog has been featured on HN before let me give you... a changelog of what's happened in the project since the last time: https://github.com/olivierlacan/keep-a-changelog/blob/master... Version 1.0 was released introducing: a much cleaner website presenting the guidelines in a more digestible way; 13 new translations; a semi-decent versioning system to help synchronize translations; and a lot of clarifications and updates based on feedback and conversations that occur regularly within the project issues: https://github.com/olivierlacan/keep-a-changelog/issues. I know trying to get ahead of the torrent of critical comments is pointless but let me summarize: yes, I know you think changelogs have been defined before. But you know just as much as I do that most changelogs (or whatever you decide to call

Read the rest

them in protest) are terrible and not as helpful to software end-users as they should be. There's been a lot of progress in the past 3 years alone in that regard. It's nearly unthinkable for an open source project to not include a decent changelog for each release. That's good. There are still a lot of smaller, less known, or older projects that could be improved with some basic changelog hygiene. If you're interesting in helping, please do, and if keepchangelog.com can help I'll be glad.

In Keep a Changelog

okket·Jul 28, 2018

Previous discussions: https://news.ycombinator.com/item?id=12370119 (45 comments, 3 years ago) https://news.ycombinator.com/item?id=9054627 (43 comments, 4 years ago) See also issues/pull requests in the repo: https://github.com/olivierlacan/keep-a-changelog

In Keep a Changelog

olivierlacan·Aug 27, 2016

Yeah, this is definitely not what I'm advocating. That sounds insane to me. Several contributors have pointed out that these conventions can be useful beyond the realm of open source so I think we've tried to make it a bit more general. It is definitely based on open source conventions though. An open source project like Rails has different components all developed within a single repository although they're packaged up independently for release. Each different component has a root level changelog that documents its changes and there isn't a centralized changelog for all of Rails. In some ways it's problematic because you can't see a merged changelog for all core components of Rails but it's also useful when you're only worried about changes to the ORM component since you'll only see changes pertaining to it within its own changelog. In m

Read the rest

y mind a changelog is a root-level concern for a single piece of software, regardless of how many isolated components it's composed of. Basic tooling should be able to centralize each changelog (as long as versions are synchronized, but that's another issue) and ideally you should be able to filter by sub-component. This is definitely not something we've created any guidelines for yet. So if you have any thoughts on the matter, feel free to suggest them: https://github.com/olivierlacan/keep-a-changelog/issues

In Keep a Changelog

olivierlacan·Aug 27, 2016

A common convention we showcase in the Keep a Changelog changelog itself (https://github.com/olivierlacan/keep-a-changelog/blob/604e38...) is to have an [Unreleased] section at the top of the changelog. It rarely conflicts with other branches of a project because it only becomes a version prior to or after a merge into the main branch (trunk/master/etc.). I'd agree this is an area we need to clarify for version 0.4.0 and forward.

In Keep a Changelog

skywinder·Mar 20, 2015

>Dumping a diff of commit logs. Just don’t do that, you’re helping nobody. (c)https://github.com/olivierlacan/keep-a-changelog It's very hard to maintain it in a good maner. The Issues fits for this purpose much better. (JMHO)

In Generate Your Changelog From GitHub Issues

olivierlacan·Feb 16, 2015

Before you run to educate me about GNU's change log style guide, please go read this: https://github.com/olivierlacan/keep-a-changelog/commit/3039... Thank you :-)

In Keep a Changelog

olivierlacan·Feb 16, 2015

I am. Based on the current status of change logs in many open source projects ((absence, poor quality, irregular updates), I believe these conventions can be improved upon and clarified. At the very least they can be explained better than a two line text file with not a single example. The GNU conventions for change logs and news files are not exactly self-explanatory (semantics matter), which probably explains how rarely they have been followed to the letter. I have no data to back this up, but I doubt people who use and depend on open source software would discard this claim. Now it's interesting to see this initiative mocked as a "not invented here syndrome" (Moru's comment). I did not define these guidelines, I merely gathered them from existing open source projects which were exceptionally good at communicating changes. The poor exam

Read the rest

ples and the frustration that fueled this project came from projects that did the opposite: - inconsistent (file naming, change categories, etc.) - dumping git diffs which provides absolutely no value to end-users (OSS software users who need to regularly update their dependencies) - littered with references to irrelevant issue trackers (which did not provide clarifications regarding the changes) - poorly written with the wrong audience in mind (fellow project collaborators who have context vs. external users who don't) - not given any dates or given confusing regionally-flavored dates - and the crux of my frustration: not singling out and emphasizing API breaking changes and deprecations Anyway, please don't dismiss this project because a convention exist in one community. This convention is not being followed for now and I would really appreciate your help in improving the status quo: https://github.com/olivierlacan/keep-a-changelog/issues Thanks.

In Keep a Changelog