debian-mirror-gitlab/doc/development/changelog.md

300 lines
12 KiB
Markdown
Raw Normal View History

2017-08-17 22:00:37 +05:30
# Changelog entries
This guide contains instructions for when and how to generate a changelog entry
file, as well as information and history about our changelog process.
## Overview
2020-04-22 19:07:51 +05:30
Each bullet point, or **entry**, in our [`CHANGELOG.md`](https://gitlab.com/gitlab-org/gitlab/blob/master/CHANGELOG.md) file is
2020-06-23 00:09:42 +05:30
generated from a single data file in the [`changelogs/unreleased/`](https://gitlab.com/gitlab-org/gitlab/tree/master/changelogs/unreleased/).
The file is expected to be a [YAML](https://en.wikipedia.org/wiki/YAML) file in the
2017-08-17 22:00:37 +05:30
following format:
```yaml
---
2018-03-17 18:26:18 +05:30
title: "Change[log]s"
2017-08-17 22:00:37 +05:30
merge_request: 1972
2020-07-28 23:09:34 +05:30
author: Black Sabbath @bsabbath
2018-03-17 18:26:18 +05:30
type: added
2017-08-17 22:00:37 +05:30
```
The `merge_request` value is a reference to a merge request that adds this
2020-07-28 23:09:34 +05:30
entry, and the `author` key (format: `<full name> <GitLab username>`) is used to give attribution to community
2017-08-17 22:00:37 +05:30
contributors. **Both are optional**.
2018-03-17 18:26:18 +05:30
The `type` field maps the category of the change,
2018-10-15 14:42:47 +05:30
valid options are: added, fixed, changed, deprecated, removed, security, performance, other. **Type field is mandatory**.
2017-08-17 22:00:37 +05:30
Community contributors and core team members are encouraged to add their name to
the `author` field. GitLab team members **should not**.
## What warrants a changelog entry?
2020-01-01 13:55:28 +05:30
- Any change that introduces a database migration, whether it's regular, post,
2020-11-24 15:15:51 +05:30
or data migration, **must** have a changelog entry, even if it is behind a
disabled feature flag.
2020-04-22 19:07:51 +05:30
- [Security fixes](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md)
**must** have a changelog entry, without `merge_request` value
2020-03-13 15:44:24 +05:30
and with `type` set to `security`.
2017-08-17 22:00:37 +05:30
- Any user-facing change **should** have a changelog entry. Example: "GitLab now
uses system fonts for all text."
2019-12-21 20:55:43 +05:30
- Performance improvements **should** have a changelog entry.
2020-10-24 23:57:45 +05:30
- Changes that need to be documented in the Telemetry [Event Dictionary](telemetry/event_dictionary.md)
also require a changelog entry.
2019-12-21 20:55:43 +05:30
- _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."
2019-12-04 20:38:33 +05:30
- Any docs-only changes **should not** have a changelog entry.
2020-10-04 03:57:07 +05:30
- 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.
2020-07-28 23:09:34 +05:30
- A change that [removes a feature flag](feature_flags/development.md) **should** have a changelog entry -
only if the feature flag did not default to true already.
2017-08-17 22:00:37 +05:30
- 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."
## Writing good changelog entries
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.
2019-09-30 21:07:59 +05:30
- **Bad:** Copy (some text) to clipboard.
2017-08-17 22:00:37 +05:30
- **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 `nil`s in the Array of Commit objects returned from
`find_commits_by_message_with_elastic`
2019-12-21 20:55:43 +05:30
- **Good:** Fix 500 errors caused by Elasticsearch results referencing
2017-08-17 22:00:37 +05:30
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
2018-03-17 18:26:18 +05:30
errors), and _when_ (searching commits with Elasticsearch).
2017-08-17 22:00:37 +05:30
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?
## How to generate a changelog entry
A `bin/changelog` script is available to generate the changelog entry file
automatically.
Its simplest usage is to provide the value for `title`:
2020-05-24 23:13:21 +05:30
```plaintext
2019-12-04 20:38:33 +05:30
bin/changelog 'Hey DZ, I added a feature to GitLab!'
```
If you want to generate a changelog entry for GitLab EE, you will need to pass
the `--ee` option:
2020-05-24 23:13:21 +05:30
```plaintext
2019-12-04 20:38:33 +05:30
bin/changelog --ee 'Hey DZ, I added a feature to GitLab!'
2017-08-17 22:00:37 +05:30
```
2020-11-24 15:15:51 +05:30
NOTE: **Note:**
All entries in the `CHANGELOG.md` file apply to all editions of GitLab.
Changelog updates are based on a common [GitLab codebase](https://gitlab.com/gitlab-org/gitlab/),
and are mirrored without proprietary code to [GitLab FOSS](https://gitlab.com/gitlab-org/gitlab-foss/) (also known as GitLab Community Edition).
2018-03-17 18:26:18 +05:30
At this point the script would ask you to select the category of the change (mapped to the `type` field in the entry):
2020-05-24 23:13:21 +05:30
```plaintext
2018-03-17 18:26:18 +05:30
>> 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
2018-12-05 23:21:45 +05:30
7. Performance improvement
8. Other
2018-03-17 18:26:18 +05:30
```
2017-08-17 22:00:37 +05:30
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 will generate a
`changelogs/unreleased/feature-hey-dz.yml` file.
The command will output the path of the generated file and its contents:
2020-05-24 23:13:21 +05:30
```plaintext
2017-08-17 22:00:37 +05:30
create changelogs/unreleased/my-feature.yml
---
title: Hey DZ, I added a feature to GitLab!
merge_request:
author:
2018-03-17 18:26:18 +05:30
type:
2017-08-17 22:00:37 +05:30
```
2019-09-30 21:07:59 +05:30
2018-03-17 18:26:18 +05:30
### Arguments
2017-08-17 22:00:37 +05:30
2019-02-15 15:39:39 +05:30
| Argument | Shorthand | Purpose |
| ----------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------- |
2019-07-07 11:18:12 +05:30
| [`--amend`](#--amend) | | Amend the previous commit |
| [`--force`](#--force-or--f) | `-f` | Overwrite an existing entry |
| [`--merge-request`](#--merge-request-or--m) | `-m` | Set merge request ID |
| [`--dry-run`](#--dry-run-or--n) | `-n` | Don't actually write anything, just print |
| [`--git-username`](#--git-username-or--u) | `-u` | Use Git user.name configuration as the author |
| [`--type`](#--type-or--t) | `-t` | The category of the change, valid options are: `added`, `fixed`, `changed`, `deprecated`, `removed`, `security`, `performance`, `other` |
| `--help` | `-h` | Print help message |
2017-08-17 22:00:37 +05:30
2019-09-30 21:07:59 +05:30
#### `--amend`
2017-08-17 22:00:37 +05:30
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 will automatically use
the "subject" of the previous commit, which is the first line of the commit
message:
2020-05-24 23:13:21 +05:30
```plaintext
2017-08-17 22:00:37 +05:30
$ 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:
2018-03-17 18:26:18 +05:30
type:
2017-08-17 22:00:37 +05:30
```
2019-09-30 21:07:59 +05:30
#### `--force` or `-f`
2017-08-17 22:00:37 +05:30
Use **`--force`** or **`-f`** to overwrite an existing changelog entry if it
already exists.
2020-05-24 23:13:21 +05:30
```plaintext
2017-08-17 22:00:37 +05:30
$ 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:
2018-03-17 18:26:18 +05:30
type:
2017-08-17 22:00:37 +05:30
```
2019-09-30 21:07:59 +05:30
#### `--merge-request` or `-m`
2017-08-17 22:00:37 +05:30
Use the **`--merge-request`** or **`-m`** argument to provide the
`merge_request` value:
2020-05-24 23:13:21 +05:30
```plaintext
2017-08-17 22:00:37 +05:30
$ 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:
2018-03-17 18:26:18 +05:30
type:
2017-08-17 22:00:37 +05:30
```
2019-09-30 21:07:59 +05:30
#### `--dry-run` or `-n`
2017-08-17 22:00:37 +05:30
Use the **`--dry-run`** or **`-n`** argument to prevent actually writing or
committing anything:
2020-05-24 23:13:21 +05:30
```plaintext
2017-08-17 22:00:37 +05:30
$ bin/changelog --amend --dry-run
create changelogs/unreleased/feature-hey-dz.yml
---
title: Added an awesome new feature to GitLab
merge_request:
author:
2018-03-17 18:26:18 +05:30
type:
2017-08-17 22:00:37 +05:30
$ ls changelogs/unreleased/
```
2019-09-30 21:07:59 +05:30
#### `--git-username` or `-u`
2017-08-17 22:00:37 +05:30
Use the **`--git-username`** or **`-u`** argument to automatically fill in the
`author` value with your configured Git `user.name` value:
2020-05-24 23:13:21 +05:30
```plaintext
2017-08-17 22:00:37 +05:30
$ 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
2018-03-17 18:26:18 +05:30
type:
```
2019-09-30 21:07:59 +05:30
#### `--type` or `-t`
2018-03-17 18:26:18 +05:30
Use the **`--type`** or **`-t`** argument to provide the `type` value:
2020-05-24 23:13:21 +05:30
```plaintext
2018-03-17 18:26:18 +05:30
$ 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
2017-08-17 22:00:37 +05:30
```
### History and Reasoning
Our `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.
2020-04-22 19:07:51 +05:30
This led us to a [boring solution](https://about.gitlab.com/handbook/values/#boring-solutions) of "add your entry in a random location in
2017-08-17 22:00:37 +05:30
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.
2020-04-22 19:07:51 +05:30
On top of all this, it created an entirely different headache for
[release managers](https://gitlab.com/gitlab-org/release/docs/blob/master/quickstart/release-manager.md)
2017-08-17 22:00:37 +05:30
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.
2020-04-22 19:07:51 +05:30
We needed to automate all of this manual work. So we
2020-06-23 00:09:42 +05:30
[started brainstorming](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/17826).
2017-08-17 22:00:37 +05:30
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
2020-04-22 19:07:51 +05:30
[release process](https://gitlab.com/gitlab-org/release-tools).
2017-08-17 22:00:37 +05:30
---
[Return to Development documentation](README.md)