@@ -46,54 +46,45 @@ naming convention `<hostpath-deployment-version>-on-<kubernetes-version>`.
46
46
## Release Process
47
47
1 . Identify all issues and ongoing PRs that should go into the release, and
48
48
drive them to resolution.
49
- 1 . Download the latest version of the
50
- [ K8s release notes generator] ( https://github.com/kubernetes/release/tree/HEAD/cmd/release-notes )
51
- 1 . Create a
52
- [ Github personal access token] ( https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token )
53
- with ` repo:public_repo ` access
54
- 1 . Generate release notes for the release. Replace arguments with the relevant
55
- information.
56
- * Clean up old cached information (also needed if you are generating release
57
- notes for multiple repos)
58
- ``` bash
59
- rm -rf /tmp/k8s-repo
60
- ```
61
- * For new minor releases on master:
62
- ` ` ` bash
63
- GITHUB_TOKEN=< token> release-notes \
64
- --discover=mergebase-to-latest \
65
- --org=kubernetes-csi \
66
- --repo=external-provisioner \
67
- --required-author=" " \
68
- --markdown-links \
69
- --output out.md
70
- ` ` `
71
- * For new patch releases on a release branch:
72
- ` ` ` bash
73
- GITHUB_TOKEN=< token> release-notes \
74
- --discover=patch-to-latest \
75
- --branch=release-1.1 \
76
- --org=kubernetes-csi \
77
- --repo=external-provisioner \
78
- --required-author=" " \
79
- --markdown-links \
80
- --output out.md
81
- ` ` `
82
- 1. Compare the generated output to the new commits for the release to check if
83
- any notable change missed a release note.
84
- 1. Reword release notes as needed. Make sure to check notes for breaking
85
- changes and deprecations.
86
- 1. If release is a new major/minor version, create a new ` CHANGELOG-< major> .< minor> .md`
87
- file. Otherwise, add the release notes to the top of the existing CHANGELOG
88
- file for that minor version.
89
- 1. Submit a PR for the CHANGELOG changes.
90
- 1. Submit a PR for README changes, in particular, Compatibility, Feature status,
91
- and any other sections that may need updating.
92
49
1 . Check that all [ canary CI
93
50
jobs] ( https://testgrid.k8s.io/sig-storage-csi-ci ) are passing,
94
51
and that test coverage is adequate for the changes that are going into the release.
95
52
1 . Check that the post-\< sidecar\> -push-images builds are succeeding.
96
53
[ Example] ( https://testgrid.k8s.io/sig-storage-image-build#post-external-snapshotter-push-images )
54
+ 1 . Generate release notes.
55
+ 1 . Download the latest version of the [ K8s release notes generator] ( https://github.com/kubernetes/release/tree/HEAD/cmd/release-notes )
56
+ 1 . Create a
57
+ [ Github personal access token] ( https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token )
58
+ with ` repo:public_repo ` access
59
+ 1 . For patch release, use the script generate_patch_release_notes.sh. Read the instructions at the top of the
60
+ script. The script also creates PRs for each branch.
61
+ 1 . For new minor releases, follow these steps and replace arguments with the relevant
62
+ information.
63
+ * Clean up old cached information (also needed if you are generating release
64
+ notes for multiple repos)
65
+ ``` bash
66
+ rm -rf /tmp/k8s-repo
67
+ ```
68
+ * For new minor releases on master:
69
+ ` ` ` bash
70
+ GITHUB_TOKEN=< token> release-notes \
71
+ --discover=mergebase-to-latest \
72
+ --org=kubernetes-csi \
73
+ --repo=external-provisioner \
74
+ --required-author=" " \
75
+ --markdown-links \
76
+ --output out.md
77
+ ` ` `
78
+ 1. Compare the generated output to the new commits for the release to check if
79
+ any notable change missed a release note.
80
+ 1. Reword release notes as needed, ideally in the original PRs so that the
81
+ release notes can be regnerated. Make sure to check notes for breaking
82
+ changes and deprecations.
83
+ 1. If release is a new major/minor version, create a new ` CHANGELOG-< major> .< minor> .md`
84
+ file.
85
+ 1. Submit a PR for the CHANGELOG changes.
86
+ 1. Submit a PR for README changes, in particular, Compatibility, Feature status,
87
+ and any other sections that may need updating.
97
88
1. Make sure that no new PRs have merged in the meantime, and no PRs are in
98
89
flight and soon to be merged.
99
90
1. Create a new release following a previous release as a template. Be sure to select the correct
0 commit comments