1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
# Unreleased changelog #
## When to add an entry? ##
All new features, user-visible changes to features, user-visible or
otherwise important infrastructure changes, and important bug fixes
should get a changelog entry.
Compatibility-breaking changes should always get a changelog entry,
which should explain what compatibility breakage is to expect.
Pull requests changing the ML API in significant ways should add an
entry in [`dev/doc/changes.md`](../../dev/doc/changes.md).
## How to add an entry? ##
Run `./dev/tools/make-changelog.sh`: it will ask you for your PR
number, and to choose among the predefined categories. Afterward,
fill in the automatically generated entry with a short description of
your change (which should describe any compatibility issues in
particular). You may also add a reference to the relevant fixed
issue, and credit reviewers, co-authors, and anyone who helped advance
the PR.
The format for changelog entries is the same as in the reference
manual. In particular, you may reference the documentation you just
added with `:ref:`, `:tacn:`, `:cmd:`, `:opt:`, `:token:`, etc. See
the [documentation of the Sphinx format](../sphinx/README.rst) of the
manual for details.
Here is a summary of the structure of a changelog entry:
``` rst
- Description of the changes, with possible link to
:ref:`relevant-section` of the updated documentation
(`#PRNUM <https://github.com/coq/coq/pull/PRNUM>`_,
[fixes `#ISSUE1 <https://github.com/coq/coq/issues/ISSUE1>`_
[ and `#ISSUE2 <https://github.com/coq/coq/issues/ISSUE2>`_],]
by Full Name[, with help / review of Full Name]).
```
|
