A changelog (also spelled change log[1]) is a log or record of all notable changes made to a project. The project is often a website or software project, and the changelog usually includes records of changes such as bug fixes, new features, etc. Some open-source projects include a changelog as one of the top-level files in their distribution.
A changelog has historically included all changes made to a project. The "Keep a Changelog" site instead advocates that a changelog not include all changes, but that it should instead contain "a curated, chronologically ordered list of notable changes for each version of a project" and should not be a "dump" of a git log "because this helps nobody".[2]
Although the GNU (Automake) canonical naming convention for the file is ChangeLog,[3] it is sometimes alternatively named as CHANGES or HISTORY (NEWS is usually a different file reflecting changes between releases, not between the commits). Another convention is to call it a CHANGELOG.[2] Some project maintainers will append a .txt suffix to the file name if the changelog is plain text, a .md suffix if it is in Markdown, or a .rst suffix if it is in reStructuredText.
Some revision control systems are able to generate the relevant information for a changelog, if the goal is to include all changes.[4]
Changelog files are organized by paragraphs, which define a unique change within a function or file.The GNU Coding standards recommend the following format:[5]
YYYY-MM-DD␣␣John Doe␣␣<johndoe@example.com>
* myfile.ext (myfunction): my changes made
additional changes.
* myfile.ext (unrelated_change): my changes made
to myfile.ext but completely unrelated to the above.
* anotherfile.ext (somefunction): more changes made by me.
Between the date and the name, and again between the name and the email address, there are two spaces each. It is common to enclose the email address in < and >. The Emacs editor creates such entries when creating additional changelog entries.
When a software is maintained under a revision control such as git or older svn or even much older cvs, and is distributed via a package like RPM Package Manager, the format of the Changelog file is different and for example:
* Mon Aug 05 2024 johndoe <johndoe@example.com> (583f243)
- myfile.ext (myfunction): my changes made additional changes.
* Fri Jul 19 2024 johndoe <johndoe@example.com> (a18761f)
- myfile.ext (unrelated_change): my changes made
to myfile.ext but completely unrelated to the above.
* Fri Jul 19 2024 johndoe <johndoe@example.com> (a739b6f)
- anotherfile.ext (somefunction): more changes made by me.
Such a file can usually be generated from the internal database of the revision control used. For example, under git, the date format must omit the time and time zone. In the command below the abbreviated commit hash is added in brackets:git log --date=format:"%a %b %d %Y" --pretty="tformat:* %ad %an <%ae> (%h)%n- %s%b%n" >ChangelogAn rpm package is itself produced from a file with a .spec extension and the revision history contained in the Changelog file is inserted at the very end, after the tag
%changelog. In order to access to the history of an installed package such as foo.rpm, the query option is--changelog:$ rpm -q --changelog foo * Mon Aug 05 2024 johndoe <johndoe@example.com> (583f243) - myfile.ext (myfunction): my changes made additional changes. ...
Most wiki software includes changelogs as a fundamental feature (often called history in this context). For example, the "View history" link at the top[6] of a Wikipedia entry links to that page's changelog. This feature is vital for complying with the attribution requirements of some copyright licenses.
A product changelog can keep customers in the loop about what's new. It helps to announce new features, latest releases, and relevant news directly in-app.