doc(readme): update versioning and compatibility matrix (#675)

Signed-off-by: Steven Zou <szou@vmware.com>

fix #673

README.md

@@ -60,38 +60,38 @@ Versions of the underlying components are listed below:
 
 |  Components   |       Harbor      | MinIO operator | PostgreSQL operator | Redis operator |
 |---------------|-------------------|----------------|---------------------|----------------|
-|  Versions     | 2.2.1 `[1]`       | 4.0.6          | 1.5.0               | 1.0.0          |
+|  Versions     | 2.2.x `[1]`       | 4.0.6          | 1.5.0               | 1.0.0          |
 
 NOTES:
 
-[1] Only one given Harbor version is supported in one operator version
+[1] `.x` means all the patch releases of Harbor can be naturally supported in one operator version.
 
 ## Compatibility
 
 ### Applicative Kubernetes versions
 
 Harbor operator supports two extra Kubernetes versions besides the current latest version (`n-2` pattern):
 
-|    Versions   |         1.18       |        1.19        |        1.20        | 1.21 |
-|---------------|--------------------|--------------------|--------------------|------|
-| Compatibility | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |  :o: |
+|    Versions   |         1.18       |        1.19        |        1.20        |           1.21            |
+|---------------|--------------------|--------------------|--------------------|---------------------------|
+| Compatibility | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |  :heavy_multiplication_x: |
 
 ### Cert manager versions
 
 Harbor operator relies on cert manager to manage kinds of certificates used by Harbor cluster components. Table shown below lists the compatibilities of cert manager versions:
 
-|    Versions   |           <0.16          |       1.0.4        |       1.2.0        | 1.3.0 |
-|---------------|--------------------------|--------------------|--------------------|-------|
-| Compatibility | :heavy_multiplication_x: | :heavy_check_mark: | :heavy_check_mark: |  :o:  |
+|    Versions   |       1.0.4        |       1.2.0        |         1.3.1        |
+|---------------|--------------------|--------------------|----------------------|
+| Compatibility | :heavy_check_mark: | :heavy_check_mark: |  :heavy_check_mark:  |
 
 ### Ingress controller types
 
 Harbor operator exposes the frontend service with ingress (CRD version: `v1beta1`). Table shown below lists the ingress controller types supported.
 
-|  Ingress Controller  |        default      |         gce        |        ncp         |
-|----------------------|---------------------|--------------------|--------------------|
-|  Compatibility       |  :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-|  Description         | Default ingress controller like NGINX | Google Cloud Engine ingress controller | NSX-T Container plugin ingress controller |
+|  Ingress Controller  |        default      |         gce        |        ncp         |        contour      |
+|----------------------|---------------------|--------------------|--------------------|---------------------|
+|  Compatibility       |  :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |  :heavy_check_mark: |
+|  Description         | Default ingress controller like NGINX | Google Cloud Engine ingress controller | NSX-T Container plugin ingress controller | Ingress controller that works by deploying the Envoy proxy |
 
 NOTES:
 

docs/LCM/upgrade-cluster.md

@@ -1,15 +1,25 @@
 # How to upgrade your Harbor cluster
 
-The harbor operator only serves a specific version of the harbor and allows to upgrade the harbor cluster instances from the old version to the latest version the operator served.
+A specified version of Harbor operator supports a corresponding Harbor minor version as well as its subsequent patch releases. e.g: harbor operator v1.0.1 supports 2.2.x harbor versions such as 2.2.0, 2.2.1 and 2.2.2 etc. For upgrading your Harbor cluster, there might be two different cases.
 
-Assume that the harbor operator v1.0.0 which serves harbor v2.2.1 is installed in the Kubernetes cluster, and there is harbor clusters deployed in the Kubernetes cluster. Now the harbor operator v1.0.1 which serves harbor v2.2.2 is released, and the users want to upgrade the three harbor clusters to v2.2.2. Here are the steps to upgrade the harbor cluster managed by the harbor operator to the new version.
+## Upgrade to patch releases
 
-1. Upgrade the harbor operator to v1.0.1 by helm or kustomize, the method depends on the original way to install the harbor operator. [Installation](../installation/installation.md) is a reference resources to upgrade the harbor operator to new release.
+The guideline shown below describes how to upgrade your Harbor cluster from lower patch version to higher patch version without operator upgrading (because there is no need as a Harbor operator version supports all patch releases).
 
-2. Edit the manifest of the harbor cluster by `kubectl` and set the `version` field to `2.2.2` in the spec.
+Assume that the harbor operator v1.0.1 which serves harbor v2.2.x is installed in the Kubernetes cluster, and there is a harbor cluster v2.2.2 deployed in the Kubernetes cluster.
+
+If you want to upgrade the harbor cluster from v2.2.2 to v2.2.3, just edit the manifest of the harbor cluster by `kubectl` and set the `version` field from `2.2.2` to `2.2.3` and the harbor operator will upgrade the harbor cluster instance to harbor v2.2.3.
+
+## Upgrade to minor+ releases
+
+For upgrading Harbor cluster across different minor versions, an operator upgrading should be involved first (because one Harbor operator version only serves one minor version serials). Steps shown below describes how to do such upgrading.
+
+1. Upgrade the harbor operator to the newer version that supports the Harbor version you're planning to upgrade your existing Harbor cluster to by `helm` or `kustomize`, the method depends on the original way to install the harbor operator. [Installation](../installation/installation.md) is a reference resources to upgrade the harbor operator to new release.
+
+1. Edit the manifest of the harbor cluster by `kubectl` and set the `version` field to the newer Harbor version (e.g:`2.3.0`) in the spec.
 
    ```bash
    kubectl -n harbor-cluster-ns edit harborclusters cluster-name
    ```
 
-3. The harbor operator will get an update event of the harbor cluster resource and reconcile to upgrade the harbor cluster to v2.2.2.
+1. The harbor operator will get an update event of the harbor cluster resource and reconcile to upgrade the harbor cluster to v2.3.0.