Gilles Peskine | b695d5e | 2020-03-27 20:06:12 +0100 | [diff] [blame] | 1 | # Pending changelog entry directory |
| 2 | |
Gilles Peskine | 7c3f7cd | 2020-03-27 19:47:35 +0100 | [diff] [blame] | 3 | This directory contains changelog entries that have not yet been merged |
| 4 | to the changelog file ([`../ChangeLog`](../ChangeLog)). |
| 5 | |
Gilles Peskine | ece00a0 | 2020-09-30 01:16:59 +0200 | [diff] [blame^] | 6 | ## What requires a changelog entry? |
| 7 | |
| 8 | Write a changelog entry if there is a user-visible change. This includes: |
| 9 | |
| 10 | * Bug fixes: fixing a security hole, fixing broken behavior, fixing |
| 11 | the build in some configuration or on some platform, ... |
| 12 | * New features in the library or new platform support. |
| 13 | * Changes in existing behavior. These should be rare. Changes in features |
| 14 | that are documented as experimental may or may not be announced, depending |
| 15 | on the extent of the change and how widely we expect the feature to be used. |
| 16 | |
| 17 | We generally don't include changelog entries for: |
| 18 | |
| 19 | * Documentation improvements. |
| 20 | * Performance improvements, unless they are particularly significant. |
| 21 | * Changes that don't impact library users directly, for example new tests or |
| 22 | changes to the test framework. |
| 23 | |
| 24 | Prior to Mbed TLS 2.24, we required changelog entries in more cases. |
| 25 | Looking at older changelog entries is good practice for how to write a |
| 26 | changelog entry, but not for deciding whether to write one. |
| 27 | |
Gilles Peskine | b695d5e | 2020-03-27 20:06:12 +0100 | [diff] [blame] | 28 | ## Changelog entry file format |
| 29 | |
Gilles Peskine | 7c3f7cd | 2020-03-27 19:47:35 +0100 | [diff] [blame] | 30 | A changelog entry file must have the extension `*.txt` and must have the |
| 31 | following format: |
| 32 | |
| 33 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 34 | Security |
| 35 | * Change description. |
| 36 | * Another change description. |
| 37 | |
| 38 | Features |
Gilles Peskine | b695d5e | 2020-03-27 20:06:12 +0100 | [diff] [blame] | 39 | * Yet another change description. This is a long change description that |
| 40 | spans multiple lines. |
Gilles Peskine | 7c3f7cd | 2020-03-27 19:47:35 +0100 | [diff] [blame] | 41 | * Yet again another change description. |
| 42 | |
| 43 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 44 | |
Gilles Peskine | b695d5e | 2020-03-27 20:06:12 +0100 | [diff] [blame] | 45 | The permitted changelog entry categories are as follows: |
| 46 | <!-- Keep this synchronized with STANDARD_CATEGORIES in assemble_changelog.py! --> |
| 47 | |
| 48 | API changes |
| 49 | Default behavior changes |
| 50 | Requirement changes |
| 51 | New deprecations |
| 52 | Removals |
| 53 | Features |
| 54 | Security |
| 55 | Bugfix |
| 56 | Changes |
| 57 | |
Gilles Peskine | ece00a0 | 2020-09-30 01:16:59 +0200 | [diff] [blame^] | 58 | Use “Changes” for anything that doesn't fit in the other categories. |
Gilles Peskine | b695d5e | 2020-03-27 20:06:12 +0100 | [diff] [blame] | 59 | |
| 60 | ## How to write a changelog entry |
| 61 | |
| 62 | Each entry starts with three spaces, an asterisk and a space. Continuation |
| 63 | lines start with 5 spaces. Lines wrap at 79 characters. |
| 64 | |
| 65 | Write full English sentences with proper capitalization and punctuation. Use |
| 66 | the present tense. Use the imperative where applicable. For example: “Fix a |
| 67 | bug in mbedtls_xxx() ….” |
| 68 | |
| 69 | Include GitHub issue numbers where relevant. Use the format “#1234” for an |
| 70 | Mbed TLS issue. Add other external references such as CVE numbers where |
| 71 | applicable. |
| 72 | |
Gilles Peskine | 3b4edc7 | 2020-09-30 01:13:05 +0200 | [diff] [blame] | 73 | Credit bug reporters where applicable. |
Gilles Peskine | b695d5e | 2020-03-27 20:06:12 +0100 | [diff] [blame] | 74 | |
| 75 | **Explain why, not how**. Remember that the audience is the users of the |
| 76 | library, not its developers. In particular, for a bug fix, explain the |
| 77 | consequences of the bug, not how the bug was fixed. For a new feature, explain |
| 78 | why one might be interested in the feature. For an API change or a deprecation, |
| 79 | explain how to update existing applications. |
| 80 | |
| 81 | See [existing entries](../ChangeLog) for examples. |
| 82 | |
| 83 | ## How `ChangeLog` is updated |
| 84 | |
| 85 | Run [`../scripts/assemble_changelog.py`](../scripts/assemble_changelog.py) |
| 86 | from a Git working copy |
| 87 | to move the entries from files in `ChangeLog.d` to the main `ChangeLog` file. |