summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKubernetes Prow Robot <k8s-ci-robot@users.noreply.github.com>2019-05-29 04:06:22 -0700
committerGitHub <noreply@github.com>2019-05-29 04:06:22 -0700
commit1ca29b8e915c6cb6d4cc0363be4ae55d8a0c8a67 (patch)
tree32852a783d45b7a60860a77ab4a90647b866cc88
parentf533b603b7eb9a4703f3e7a6428d78288a0bf3c0 (diff)
parent99036508f1721df34351542a3dd26680689c422b (diff)
Merge pull request #3743 from gaorong/broken-link
fix broken links
-rw-r--r--contributors/design-proposals/release/versioning.md4
1 files changed, 2 insertions, 2 deletions
diff --git a/contributors/design-proposals/release/versioning.md b/contributors/design-proposals/release/versioning.md
index 05e7faed..da7f1bbb 100644
--- a/contributors/design-proposals/release/versioning.md
+++ b/contributors/design-proposals/release/versioning.md
@@ -70,7 +70,7 @@ especially for production-critical components.
We expect users to be running approximately the latest patch release of a given
minor release; we often include critical bug fixes in
-[patch releases](#patch-release), and so encourage users to upgrade as soon as
+[patch releases](#patch-releases), and so encourage users to upgrade as soon as
possible.
Different components are expected to be compatible across different amounts of
@@ -114,7 +114,7 @@ version changes, not new major nor minor versions).
rolling upgrade across their cluster. (Rolling upgrade means being able to
upgrade the master first, then one node at a time. See [#4855](https://issues.k8s.io/4855) for details.)
* However, we do not recommend upgrading more than two minor releases at a
-time (see [Supported releases](#supported-releases)), and do not recommend
+time (see [Supported releases and component skew](#Supported-releases-and-component-skew)), and do not recommend
running non-latest patch releases of a given minor release.
* No hard breaking changes over version boundaries.
* For example, if a user is at Kube 1.x, we may require them to upgrade to