[exratione]

I'd argue that the goal of creating a good, useful changelog can be one of the forcing motivations to establish a working process for commit documentation and great, informative, useful commit messages. If that means git log gardening after the fact, then so be it, but good documentation (of history here) is always worth the work.

The activities of programmer-archaeology are always made so much easier if you have a screed of history for each area of interest in the codebase. Sadly that's still rare, even in groups that do the necessary work to maintain their documentation for the current state of HEAD. There are many times when history matters, is relevant, and those who do not learn it are doomed to repeat it - or at the very least build elaborate theories to explain what happened in the past in order to understand how the present came to be where it is.

The great changelog built on great commit history is probably hard to do outside of a small, focused group. On the other hand, the pull request process has emerged and developers have embraced that level of work, so it feels like it should be achievable.

[olivierlacan]

I agree. Maintaining a changelog can be certainly be more difficult in large projects (although I don't think it has to be). I do think changelogs are a manifestation of the maintainers' care with regard to end-users. It signifies that they don't simply focus on the quality of the project itself but also how the project's evolution is perceived and understood by end-users and fellow contributors.

It's strange to me that anyone would consider especially open source software as something so good and obviously beneficial that the archeology you mention would be a fact of life for end-users. It betrays a misconception about the value of software in a vacuum: without tests, code documentation, interface design, and change documentation (a changelog).

The best algorithm is useless without proper tests verifying how it functions against real input; it's obscure without good documentation highlighting its quirks and design decisions, and if it evolves without clear explanations within a changelog then the changes in its behavior will remain mysteries to end-users as long as they don't go deep inside the code to understand how it worked before and how it works now.

I've had to do this kind of programmer-archeology on numerous production dependencies (transitive or otherwise) in the past and the resulting frustration is very much the fuel that motivated me to make keepachangelog.com