6.8.3 Simple Changes

Certain simple kinds of changes don’t need much detail in the change log.

If the description of the change is short enough, it can serve as its own header line:

2019-08-29  Eli Zaretskii  <[email protected]>

	* lisp/simple.el (kill-do-not-save-duplicates): Doc fix.  (Bug#36827)

When you change the calling sequence of a function in a simple fashion, and you change all the callers of the function to use the new calling sequence, there is no need to make individual entries for all the callers that you changed. Just write in the entry for the function being called, “All callers changed”—like this:

* keyboard.c (Fcommand_execute): New arg SPECIAL.
All callers changed.

When you change just comments or doc strings, it is enough to write an entry for the file, without mentioning the functions. Just “Doc fixes” is enough for the change log.

When you make changes in many files that follow mechanically from one underlying change, it is enough to describe the underlying change. Here’s an example of a change that affects all of the files in the repository:

2019-01-07  Paul Eggert  <[email protected]>

	Update copyright year to 2019

	Run 'TZ=UTC0 admin/update-copyright $(git ls-files)'.

Test suite files are part of the software, so we recommend treating them as code for change-log purposes.

There’s no technical need to make change log entries for non-software files (manuals, help files, media files, etc.). This is because they are not susceptible to bugs that are hard to understand. To correct an error, you need not know the history of the erroneous passage; it is enough to compare what the file says with the actual facts.

However, you should keep change logs for non-software files when the project gets copyright assignments from its contributors, so as to make the records of authorship more accurate. For that reason, we recommend to keep change logs for Texinfo sources of your project’s manuals.