@@ -100,6 +100,10 @@ to match the PR. For instance, if you have a bugfix in with a breaking
100
100
change, it's generally encouraged to submit the bugfix separately, but if
101
101
you must put them in one PR, mark the commit separately.
102
102
103
+ * Commits marked separately will be treated similiarly to a distinct PR by
104
+ the cherrypick scripts* . Therefore, only use them if you want the given
105
+ commit to be considered separately.
106
+
103
107
### Commands and Workflow
104
108
105
109
controller-runtime follows the standard Kubernetes workflow: any PR needs
@@ -126,17 +130,15 @@ will evaluate when to do a major release as it comes up.
126
130
127
131
### Exact Steps
128
132
129
- 1 . Generate release notes using the release note tooling (*** TODO*** )
130
-
131
- 2 . Add a release for controller-runtime on GitHub, using those release
132
- notes
133
+ 1 . (* if doing a minor or patch release* ) Update the release-X branch with
134
+ the latest set of changes using the cherrypick tooling (*** TODO*** )
133
135
134
- 3 . Add a release for controller-tools on GitHub (folowing a similar
135
- process for controller-tools release notes).
136
+ 2 . Generate release notes using the release note tooling (*** TODO*** )
136
137
137
- 4 . Publish associated binaries and release tarballs (*** TODO*** )
138
+ 3 . Add a release for controller-runtime on GitHub, using those release
139
+ notes, with a title of ` vX.Y.Z ` .
138
140
139
- 5 . Announce the release in ` #kubebuilder ` on Slack with a pinned message.
141
+ 4 . Announce the release in ` #kubebuilder ` on Slack with a pinned message.
140
142
141
143
### Breaking Changes
142
144
0 commit comments