@@ -8,20 +8,28 @@ relevant to people working on the code itself.)
8
8
Each file should be named like ``<ISSUE>.<TYPE>.rst ``, where
9
9
``<ISSUE> `` is an issue numbers, and ``<TYPE> `` is one of:
10
10
11
- * ``feature ``
11
+ * ``headline ``: a major new feature we want to highlight for users
12
+ * ``breaking ``: any breaking changes that happen without a proper
13
+ deprecation period (note: deprecations, and removal of previously
14
+ deprecated features after an appropriate time, go in the
15
+ ``deprecated `` category instead)
16
+ * ``feature ``: any new feature that doesn't qualify for ``headline ``
12
17
* ``bugfix ``
13
18
* ``doc ``
14
- * ``removal ``
19
+ * ``deprecated ``
15
20
* ``misc ``
16
21
17
- So for example: ``123.feature.rst ``, ``456.bugfix.rst ``
22
+ So for example: ``123.headline.rst ``, ``456.bugfix.rst ``,
23
+ ``789.deprecated.rst ``
18
24
19
25
If your PR fixes an issue, use that number here. If there is no issue,
20
26
then after you submit the PR and get the PR number you can add a
21
27
newsfragment using that instead.
22
28
23
- Note that the ``towncrier `` tool will automatically
24
- reflow your text, so don't try to do any fancy formatting. You can
25
- install ``towncrier `` and then run ``towncrier --draft `` if you want
26
- to get a preview of how your change will look in the final release
27
- notes.
29
+ Your text can use all the same markup that we use in our Sphinx docs.
30
+ For example, you can use double-backticks to mark code snippets, or
31
+ single-backticks to link to a function/class/module.
32
+
33
+ To check how your formatting looks, the easiest way is to make the PR,
34
+ and then after the CI checks run, click on the "Read the Docs build"
35
+ details link, and navigate to the release history page.
0 commit comments