Suggestion to use a CHANGELOG file

General
1

Continuing the discussion from Changelogs for v0.12.15 to v0.12.25:

Thanks for the clarifications on the thread above, however I still wonder why not having a CHANGELOG file like most other projects. Asking users to read the commits log can’t be the real solution.

The situation happened just today to me, seeing the package upgrade from 0.12.24 to 0.13.0 in aptitude, I wanted to quickly check what’s new, what has changed and possibly any thing to know before starting the upgrade.

My first reflex is to check the CHANGELOG on the upstream repository. After seeing that there was none, I remembered that until then I could see the changelogs through the releases on Github (while it is kind of a solution, that centralize the changelog to Github and brings a hard dependancy on Github for that). Checking the Forum to find a thread about the changelogs wasn’t hard either (here I am), but that’s already 2 level of indirection since the first attempt to read the (expected) CHANGELOG file.

TL;DR: I strongly support the idea to have a CHANGELOG text file in the root of the repository to make the life of everyone easier. What do you think?

3 Likes
2

Feel free to compile it and propose a pull request.

3

Well, before investing time into that, I wanted to get the opinion from upstream about maintaining a CHANGELOG in the repo in the future.

Would the core developers want to have it at the first place? to maintain it? (I guess updating it during the release process would suffice).

4

We upload the release notes into the github release page anyway, so don’t see why adding it to CHANGELOG would be too much trouble, especially if it’s automated.

Though before you jump in, let’s see what @calmh has to say.

5

I’ve adopted typing the release notes into the tag message. That’s persistent enough I think. I don’t want to commit to keeping a CHANGELOG right now, but if we change our minds in the future it can be trivially generated from the tag messages.

3 Likes