You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: release-notes.md
+15-93Lines changed: 15 additions & 93 deletions
Original file line number
Diff line number
Diff line change
@@ -3,100 +3,22 @@ layout: default
3
3
title: How to prepare Rust release notes · The Rust Programming Language
4
4
---
5
5
6
-
_[Originally posted to the "milestone predictions" thread on internals.rlo](https://internals.rust-lang.org/t/rust-release-milestone-predictions/4591/33)._
6
+
The release notes for the next release should be compiled at the beginning of
7
+
the beta cycle, 6 weeks ahead of the release.
7
8
8
-
Ideally the notes for the next release are compiled at the beginning
9
-
of the beta cycle, 6 weeks ahead of the release.
9
+
Clone the [relnotes] utility. This program pulls all pull requests made against
10
+
`rust-lang/rust` and `rust-lang/cargo` within the latest release cycle and
11
+
prints out a markdown document containing all the pull requests, categorised
12
+
into their respective sections where possible, and prints the document to
13
+
`stdout`.
10
14
11
-
Copy the previous version's section in README.md to a new section and
12
-
strip out all the items. Reuse the existing section structure, but
13
-
look out for themes in the release that might warrant other
14
-
sections. e.g. sometimes there's a lot of interesting perf commits, or
15
-
rustdoc commits.
15
+
Only pull requests that impact stable users of Rust should be included.
16
+
Generally, more exciting items go toward the top of sections. Most items are
17
+
simply links to the PR that landed them; some that need more explanation have
18
+
additional, unlinked text; anything supported by an RFC has an additional RFC
19
+
link. Reuse the PR titles or write descriptions as needed for clarity.
16
20
17
-
Before I start I find the date ranges the release was on master, for
18
-
making GitHub queries, and the commit ranges for the entire release,
19
-
as well as commit ranges for just the releases backports.
21
+
Try to keep the language of the document independent of en-US or en-UK, when
22
+
it can't be avoided defer to en-US grammar and syntax.
20
23
21
-
I only pick out PRs that impact stable features. Currently, nightly
22
-
development does not have a place in the release notes. Generally,
23
-
more exciting items go toward the top of sections. Most items are
24
-
simply links to the PR that landed them; some that need more
25
-
explanation have additional, unlinked text; anything supported by an
26
-
RFC has an additional RFC link. I reuse the PR titles or write my
27
-
own descriptions as needed for clarity.
28
-
29
-
The main query I do is against GitHub merges for rust-lang/rust for
0 commit comments