Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comments
Comment #1
DamienMcKennaFrom 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?
Comment #2
DamienMcKennaIt'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.
Comment #4
Dave ReidReopening 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 Drupal.org. 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.
Comment #5
DamienMcKennaOTOH 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.
Comment #6
DamienMcKennaAlso, just to mention it, I'm completely happy maintaining the file, like I've done for the past few years.