diff --git a/release_notes/images/redcircle-1.png b/release_notes/images/redcircle-1.png
new file mode 100644
index 000000000000..4cbb364a2d76
Binary files /dev/null and b/release_notes/images/redcircle-1.png differ
diff --git a/release_notes/images/redcircle-2.png b/release_notes/images/redcircle-2.png
new file mode 100644
index 000000000000..23f4a0d23f93
Binary files /dev/null and b/release_notes/images/redcircle-2.png differ
diff --git a/release_notes/images/redcircle-3.png b/release_notes/images/redcircle-3.png
new file mode 100644
index 000000000000..06ac69f6a99c
Binary files /dev/null and b/release_notes/images/redcircle-3.png differ
diff --git a/release_notes/index.adoc b/release_notes/index.adoc
index 393fe8be6b1c..c6c74bcfdc1c 100644
--- a/release_notes/index.adoc
+++ b/release_notes/index.adoc
@@ -24,16 +24,21 @@ endif::[]
 == Versioning Policy
 
 {product-title} provides strict backwards compatibility guarantees for all
-supported APIs (excluding alpha APIs, which may be changed without notice, and
-beta APIs, which may occasionally be changed in a non-backwards compatible
-manner). {product-title} will continue to support older clients against newer
-servers. For example, a 3.4 client will work against 3.3, 3.4, and 3.5 servers.
+supported APIs, excluding alpha APIs (which may be changed without notice) and
+beta APIs (which may occasionally be changed in a non-backwards compatible
+manner).
+
+The {product-title} version must match between master and node hosts, excluding
+temporary mismatches during cluster upgrades. For example, in a 3.5 cluster, all
+masters must be 3.5 and all nodes must be 3.5. However, {product-title} will
+continue to support older `oc` clients against newer servers. For example, a 3.4
+`oc` will work against 3.3, 3.4, and 3.5 servers.
 
 Changes of APIs for non-security related reasons will involve, at minimum, two
-minor releases (3.1 to 3.2 to 3.3, for example) to allow older clients to
-update. Using new capabilities may require newer clients. A 3.2 server may have
-additional capabilities that a 3.1 client cannot use and a 3.2 client may have
-additional capabilities that are not supported by a 3.1 server.
+minor releases (3.1 to 3.2 to 3.3, for example) to allow older `oc` to update.
+Using new capabilities may require newer `oc`. A 3.2 server may have additional
+capabilities that a 3.1 `oc` cannot use and a 3.2 `oc` may have additional
+capabilities that are not supported by a 3.1 server.
 
 .Compatibility Matrix
 
@@ -41,19 +46,18 @@ additional capabilities that are not supported by a 3.1 server.
 |===
 
 |
-|*X.Y* (Client)
-|*X.Y+N* footnoteref:[versionpolicyn,Where *N* is a number greater than 1.] (Client)
+|*X.Y* (`oc` Client)
+|*X.Y+N* footnoteref:[versionpolicyn,Where *N* is a number greater than 1.] (`oc` Client)
 
 |*X.Y* (Server)
-|1
-|3
+|image:redcircle-1.png[]
+|image:redcircle-3.png[]
 
 |*X.Y+N* footnoteref:[versionpolicyn] (Server)
-|2
-|1
+|image:redcircle-2.png[]
+|image:redcircle-1.png[]
 
 |===
-
 <1> Fully compatible.
-<2> Client may not be able to access server features.
-<3> Client may provide options and features that may not be compatible with the accessed server.
+<2> `oc` client may not be able to access server features.
+<3> `oc` client may provide options and features that may not be compatible with the accessed server.