@@ -11,24 +11,31 @@ verified:
11
11
12
12
1 . Create release pull request with release notes and updated versions.
13
13
14
- 1 . Compile release notes detailing features added since the last release and
14
+ 1 . Review all pull requests merged into the release. For any pull request
15
+ that should be highlighted in the release notes, add the appropriate
16
+ ` impact/* ` and ` area/* ` labels. Update the title to match the style used
17
+ in release notes. Normally the titles are short descriptions starting with
18
+ a present tense verb and optionally prepended with square brackets section
19
+ which usually includes release branch.
20
+
21
+ 2 . Compile release notes with summary of changes since the last release and
15
22
add release template file to ` releases/ ` directory. The template is defined
16
23
by containerd's release tool but refer to previous release files for style
17
24
and format help. Name the file using the version, for rc add an ` -rc ` suffix.
18
25
When moving from rc to final, the rc file may just be renamed and updated.
19
26
See [ release-tool] ( https://github.com/containerd/release-tool )
20
27
21
- 2 . Update the version file at ` https://github.com/containerd/containerd/blob/main/version/version.go `
28
+ 3 . Update the version file at ` https://github.com/containerd/containerd/blob/main/version/version.go `
22
29
23
- 3 . (major/minor release only) Update RELEASES.md to refer to the new release and dates.
30
+ 4 . (major/minor release only) Update RELEASES.md to refer to the new release and dates.
24
31
25
- 4 . Update the ` .mailmap ` files for commit authors which have multiple email addresses in the commit log.
32
+ 5 . Update the ` .mailmap ` files for commit authors which have multiple email addresses in the commit log.
26
33
If it is not clear which email or name the contributor might want used in the release notes, reach
27
34
out to the contributor for feedback. NOTE: real names should be used whenever possible. The file is
28
35
maintained by manually adding entries to the file.
29
36
- e.g.
` Real Name <[email protected] > Other Name <[email protected] > `
30
37
31
- 5 . Before opening the pull request, run the release tool using the new release notes.
38
+ 6 . Before opening the pull request, run the release tool using the new release notes.
32
39
Ensure the output matches what is expected, including contributors, change log,
33
40
dependencies, and visual elements such as spacing. If a contributor is duplicated,
34
41
use the emails outputted by the release tool to update the mailmap then re-run. The
@@ -41,7 +48,8 @@ verified:
41
48
expects tags to be formatted as ` vx.y.z[-rc.n] ` .
42
49
43
50
2 . Generate release notes (using a temp file may be helpful).
44
- - e.g. ` release-tool -l -d -n -t v1.0.0 ./releases/v1.0.0.toml > /tmp/v1.0.0-notes `
51
+ - e.g. ` release-tool -r -g -d -n -t v1.0.0 ./releases/v1.0.0.toml > /tmp/v1.0.0-notes `
52
+ - if release notes are too long, such as for major/minor releases, add ` --skip-commits ` option
45
53
46
54
3 . Create tag using the generated release notes.
47
55
- e.g. ` git tag --cleanup=whitespace -s v1.0.0 -F /tmp/v1.0.0-notes `
0 commit comments