At the start of the bootsrap script (from Gnulib). It suggests: "consider installing git-merge-changelog from gnulib". After searching for "changelog" in gnulib, I saw there is also another script: "gitlog-to-changelog". These might also be interesting alternatives, besides the emacs solution. Since they are in Gnulib, it might be easier to use in Gnuastro. But it would be interesting to do a nice comparison and see how they all work and make the best choice.

Thanks for the link. From now on, we can stop adding to the ChangeLog. I have just added a "For v0.1:" to the title to explicitly mark this task as something that should be done before the release of version 0.1. In this way, a simple search in the open tasks will highlight anything we haven't done yet.

In the meantime we can think if we want to stop updating the ChangeLog like GSL or use a script like the Emacs example and generate it prior to each release automatically.

I have marked the completion to 10% since at least we have decided to not update ChangeLog any more. Once we decide how to implement it from the two options above, we can make it 100% and mark it as closed.

Maybe we can follow this way of putting a "For vN.N:" prior to the titles of each task that is agreed upon to do prior to any release but doesn't need immediate attention.

This is a completely reasonable argument and I agree. Until now I would only keep the changes (as opposed to additions) in the ChangeLog and try to explain both in the commit messages.

Git commit messages and the corresponding changes have all the information we might need and the problem with merge conflicts you mentioned are completely true.

I am just thinking about a good way to deploy it (remove the ChangeLog) while also satisfying the GNU Coding Standards. I think the NEWS file is probably enough for the users who only download Gnuastro's released tar.gz file, the ChangeLog is too detailed for them.