Merge pull request #198 from hongchaodeng/doc

docs: minor fix on upgrade

design/cluster_upgrade.md

@@ -1,12 +1,10 @@
 # Cluster upgrade
 
-etcd supports rolling upgrade from one minor release version to its next minor release version. For example, we can directly upgrade etcd 2.3.1 to 2.3.2. But it is usually unsupported to upgrade etcd from one version to its next next release version. For example, we should not directly upgrade etcd 2.3.1 to 2.3.3. So we should update etcd one version a time.
-
-etcd supports rolling upgrade within one minor release. For example, we can directly upgrade a 2.3.1 cluster directly to 2.3.8.
+- etcd supports rolling upgrade from one minor release version to its next minor release version. For example, we can directly upgrade etcd 3.0.7 to 3.1.0.
+- etcd supports rolling upgrade within one minor release. For example, we can upgrade etcd 3.0.1 to 3.0.7.
+- etcd supports minor version upgrade unconcerned with patch version, e.g. from 3.0.1 to 3.1.0. Nonetheless it's recommended to upgrade from 3.0.1 to 3.0.n (n is latest) and then from 3.0.n to 3.1.0.
 
 ## Rolling upgrade
 
-We upgrade one member a time duing a cluster upgrade. To upgrade that member, we simply update the pod manifest with the desired version of etcd container. We need to clear all --initial prefix flags previously set.
-
-
+We upgrade one member at a time during a cluster upgrade. To upgrade that member, we simply update the pod manifest with the desired version of etcd container. We need to clear all --initial prefix flags previously set.