It's unnecessary given that we have Git and the easy ability to pull up changelogs between versions. Having CHANGELOG.txt makes maintaining multiple branches more difficult since always adding a new line at the 'end' of the current section will always conflict with something else that adds a line. It's also one more thing to have to remember to change on a commit when we can pull that information from Git later in a more reliable format.


DamienMcKenna’s picture

From the site builder perspective, I've always found it useful to have a CHANGELOG.txt file right there, just like core has. How does core deal with multiple branches?

DamienMcKenna’s picture

Status: Active » Fixed

It's still a best practice to use a CHANGELOG.txt file, even if you're just a co-maintainer ;)

I really want to keep this file around and I'll take responsibility for keeping it accurate.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Dave Reid’s picture

Issue summary: View changes
Status: Closed (fixed) » Active

Reopening this. Even Views doesn't maintain a changelog, and I'm pretty sure the recommendation for having CHANGELOG.txt pre-existed when we had tools like git release-notes that made it easy to generate release notes for us and build the change logs for us. Also, any major changes should now be documented with change notices directly on For example, luckily I caught #2678896: hook_metatag_info() labels are double-translated early, but it would have been more of a pain in the ass if more things had been committed after it.

DamienMcKenna’s picture

Status: Active » Closed (won't fix)

OTOH I find them extremely useful to identify changes between releases, especially when a site is using dev releases.

And yes, I need to not forget to write change notices, but that's a separate issue to having the CHANGELOG.txt.

DamienMcKenna’s picture

Also, just to mention it, I'm completely happy maintaining the file, like I've done for the past few years.