- What warrants a changelog entry?
- Writing good changelog entries
- How to generate a changelog entry
This guide contains instructions for when and how to generate a changelog entry file, as well as information and history about our changelog process.
--- title: "Change[log]s" merge_request: 1972 author: Black Sabbath @bsabbath type: added
merge_request value is a reference to a merge request that adds this
entry, and the
author key (format:
<full name> <GitLab username>) is used to give attribution to community
contributors. Both are optional.
type field maps the category of the change,
valid options are: added, fixed, changed, deprecated, removed, security, performance, other. Type field is mandatory.
Community contributors and core team members are encouraged to add their name to
author field. GitLab team members should not.
Any change that introduces a database migration, whether it’s regular, post, or data migration, must have a changelog entry, even if it is behind a disabled feature flag. Since the migration is executed on GitLab FOSS, the changelog for database schema changes should be written to the
changelogs/unreleased/directory, even when other elements of that change affect only GitLab EE.
must have a changelog entry, without
merge_requestvalue and with
- Any user-facing change must have a changelog entry. This includes both visual changes (regardless of how minor), and changes to the rendered DOM which impact how a screen reader may announce the content.
- Any client-facing change to our REST and GraphQL APIs must have a changelog entry. This includes modifying complexity of GraphQL fields.
- Performance improvements should have a changelog entry.
- Changes that need to be documented in the Product Intelligence Event Dictionary also require a changelog entry.
- Any contribution from a community member, no matter how small, may have a changelog entry regardless of these guidelines if the contributor wants one. Example: “Fixed a typo on the search results page.”
- Any docs-only changes should not have a changelog entry.
- Any change behind a disabled feature flag should not have a changelog entry.
- Any change behind an enabled feature flag should have a changelog entry.
- Any change that adds new usage data metrics and changes that needs to be documented in Product Intelligence Event Dictionary should have a changelog entry.
- A change that adds snowplow events should have a changelog entry -
- A change that removes a feature flag should have a changelog entry - only if the feature flag did not default to true already.
- A fix for a regression introduced and then fixed in the same release (i.e., fixing a bug introduced during a monthly release candidate) should not have a changelog entry.
- Any developer-facing change (e.g., refactoring, technical debt remediation, test suite changes) should not have a changelog entry. Example: “Reduce database records created during Cycle Analytics model spec.”
A good changelog entry should be descriptive and concise. It should explain the change to a reader who has zero context about the change. If you have trouble making it both concise and descriptive, err on the side of descriptive.
- Bad: Go to a project order.
- Good: Show a user’s starred projects at the top of the “Go to project” dropdown.
The first example provides no context of where the change was made, or why, or how it benefits the user.
- Bad: Copy (some text) to clipboard.
- Good: Update the “Copy to clipboard” tooltip to indicate what’s being copied.
Again, the first example is too vague and provides no context.
- Bad: Fixes and Improves CSS and HTML problems in mini pipeline graph and builds dropdown.
- Good: Fix tooltips and hover states in mini pipeline graph and builds dropdown.
The first example is too focused on implementation details. The user doesn’t care that we changed CSS and HTML, they care about the end result of those changes.
Bad: Strip out
nils in the Array of Commit objects returned from
- Good: Fix 500 errors caused by Elasticsearch results referencing garbage-collected commits
The first example focuses on how we fixed something, not on what it fixes. The rewritten version clearly describes the end benefit to the user (fewer 500 errors), and when (searching commits with Elasticsearch).
Use your best judgement and try to put yourself in the mindset of someone reading the compiled changelog. Does this entry add value? Does it offer context about where and why the change was made?
bin/changelog script is available to generate the changelog entry file
Its simplest usage is to provide the value for
bin/changelog 'Hey DZ, I added a feature to GitLab!'
If you want to generate a changelog entry for GitLab EE, you must pass
bin/changelog --ee 'Hey DZ, I added a feature to GitLab!'
All entries in the
CHANGELOG.md file apply to all editions of GitLab.
Changelog updates are based on a common GitLab codebase,
and are mirrored without proprietary code to GitLab FOSS (also known as GitLab Community Edition).
At this point the script would ask you to select the category of the change (mapped to the
type field in the entry):
>> Please specify the category of your change: 1. New feature 2. Bug fix 3. Feature change 4. New deprecation 5. Feature removal 6. Security fix 7. Performance improvement 8. Other
The entry filename is based on the name of the current Git branch. If you run
the command above on a branch called
feature/hey-dz, it generates a
The command outputs the path of the generated file and its contents:
create changelogs/unreleased/my-feature.yml --- title: Hey DZ, I added a feature to GitLab! merge_request: author: type:
|Amend the previous commit|
|Overwrite an existing entry|
|Set merge request ID|
|Don’t actually write anything, just print|
|Use Git user.name configuration as the author|
|The category of the change, valid options are: |
|Create an EE changelog|
|Print help message|
You can pass the
--amend argument to automatically stage the generated
file and amend it to the previous commit.
If you use
--amend and don’t provide a title, it uses
the “subject” of the previous commit, which is the first line of the commit
$ git show --oneline ab88683 Added an awesome new feature to GitLab $ bin/changelog --amend create changelogs/unreleased/feature-hey-dz.yml --- title: Added an awesome new feature to GitLab merge_request: author: type:
-f to overwrite an existing changelog entry if it
$ bin/changelog 'Hey DZ, I added a feature to GitLab!' error changelogs/unreleased/feature-hey-dz.yml already exists! Use `--force` to overwrite. $ bin/changelog 'Hey DZ, I added a feature to GitLab!' --force create changelogs/unreleased/feature-hey-dz.yml --- title: Hey DZ, I added a feature to GitLab! merge_request: 1983 author: type:
-m argument to provide the
$ bin/changelog 'Hey DZ, I added a feature to GitLab!' -m 1983 create changelogs/unreleased/feature-hey-dz.yml --- title: Hey DZ, I added a feature to GitLab! merge_request: 1983 author: type:
-n argument to prevent actually writing or
$ bin/changelog --amend --dry-run create changelogs/unreleased/feature-hey-dz.yml --- title: Added an awesome new feature to GitLab merge_request: author: type: $ ls changelogs/unreleased/
-u argument to automatically fill in the
author value with your configured Git
$ git config user.name Jane Doe $ bin/changelog -u 'Hey DZ, I added a feature to GitLab!' create changelogs/unreleased/feature-hey-dz.yml --- title: Hey DZ, I added a feature to GitLab! merge_request: author: Jane Doe type:
-t argument to provide the
$ bin/changelog 'Hey DZ, I added a feature to GitLab!' -t added create changelogs/unreleased/feature-hey-dz.yml --- title: Hey DZ, I added a feature to GitLab! merge_request: author: type: added
--ee argument to create an EE changelog:
$ bin/changelog 'Hey DZ, I added a feature to GitLab!' -ee create ee/changelogs/unreleased/feature-hey-dz.yml --- title: Hey DZ, I added a feature to GitLab! merge_request: author: type: added
CHANGELOG file was previously updated manually by each contributor that
felt their change warranted an entry. When two merge requests added their own
entries at the same spot in the list, it created a merge conflict in one as soon
as the other was merged. When we had dozens of merge requests fighting for the
same changelog entry location, this quickly became a major source of merge
conflicts and delays in development.
This led us to a boring solution of “add your entry in a random location in the list.” This actually worked pretty well as we got further along in each monthly release cycle, but at the start of a new cycle, when a new version section was added and there were fewer places to “randomly” add an entry, the conflicts became a problem again until we had a sufficient number of entries.
On top of all this, it created an entirely different headache for
when they cherry-picked a commit into a stable branch for a patch release. If
the commit included an entry in the
CHANGELOG, it would include the entire
changelog for the latest version in
master, so the release manager would have
to manually remove the later entries. They often would have had to do this
multiple times per patch release. This was compounded when we had to release
multiple patches at once due to a security issue.
We needed to automate all of this manual work. So we
After much discussion we settled on the current solution of one file per entry,
and then compiling the entries into the overall
CHANGELOG.md file during the