@@ -66,7 +66,7 @@ greatest code, including breaking changes, happens on master.
66
66
The * release-X* branches contain stable, backwards compatible code. Every
67
67
major (X) release, a new such branch is created. It is from these
68
68
branches that minor and patch releases are tagged. If some cases, it may
69
- be neccessary open PRs for bugfixes directly against stable branches, but
69
+ be necessary open PRs for bugfixes directly against stable branches, but
70
70
this should generally not be the case.
71
71
72
72
The maintainers are responsible for updating the contents of this branch;
@@ -131,7 +131,7 @@ branch, except in exceptional circumstances. Patches will be backported
131
131
to maintained stable versions, as needed.
132
132
133
133
Major releases are done shortly after a breaking change is merged -- once
134
- a breaking change is merged, the next release * must* be a major revison .
134
+ a breaking change is merged, the next release * must* be a major revision .
135
135
We don't intend to have a lot of these, so we may put off merging breaking
136
136
PRs until a later date.
137
137
@@ -172,9 +172,9 @@ have to rewrite their code when they eventually upgrade, and for
172
172
maintainers/contributors, who have to deal with differences between master
173
173
and stable branches.
174
174
175
- That being said, we'll occaisonally want to make breaking changes. They'll
175
+ That being said, we'll occasionally want to make breaking changes. They'll
176
176
be merged onto master, and will then trigger a major release (see [ Release
177
- Proccess ] ( #release-process ) ). Because breaking changes induce a major
177
+ Process ] ( #release-process ) ). Because breaking changes induce a major
178
178
revision, the maintainers may delay a particular breaking change until
179
179
a later date when they are ready to make a major revision with a few
180
180
breaking changes.
@@ -187,7 +187,7 @@ Maintainers should treat breaking changes with caution, and evaluate
187
187
potential non-breaking solutions (see below).
188
188
189
189
Note that API breakage in public APIs due to dependencies will trigger
190
- a major revision, so you may occaisonally need to have a major release
190
+ a major revision, so you may occasionally need to have a major release
191
191
anyway, due to changes in libraries like ` k8s.io/client-go ` or
192
192
` k8s.io/apimachinery ` .
193
193
0 commit comments