From 99036508f1721df34351542a3dd26680689c422b Mon Sep 17 00:00:00 2001 From: Rong Gao Date: Wed, 29 May 2019 16:51:03 +0800 Subject: [PATCH] fix broken links --- contributors/design-proposals/release/versioning.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contributors/design-proposals/release/versioning.md b/contributors/design-proposals/release/versioning.md index 05e7faed7..da7f1bbb7 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