update documents

Signed-off-by: Ziming Zhang <zziming@vmware.com>

docs/LCM/upgrade-cluster.md

@@ -1,25 +1,25 @@
 # How to upgrade your Harbor cluster
 
-A specified version of Harbor operator supports a corresponding Harbor minor version as well as its subsequent patch releases. e.g: harbor operator v1.2.0 supports 2.4.x harbor versions such as 2.4.0, 2.4.1 and 2.4.2 etc. For upgrading your Harbor cluster, there might be two different cases.
+A specified version of Harbor operator supports a corresponding Harbor minor version as well as its subsequent patch releases. e.g: harbor operator v1.3.0 supports 2.5.x harbor versions such as 2.5.0, 2.5.1 and 2.5.2 etc. For upgrading your Harbor cluster, there might be two different cases.
 
 ## Upgrade to patch releases
 
 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).
 
-Assume that the harbor operator v1.2.0 which serves harbor v2.4.x is installed in the Kubernetes cluster, and there is a harbor cluster v2.4.0 deployed in the Kubernetes cluster.
+Assume that the harbor operator v1.3.0 which serves harbor v2.5.x is installed in the Kubernetes cluster, and there is a harbor cluster v2.5.0 deployed in the Kubernetes cluster.
 
-If you want to upgrade the harbor cluster from v2.4.0 to v2.4.1, just edit the manifest of the harbor cluster by `kubectl` and set the `version` field from `2.4.0` to `2.4.1` and the harbor operator will upgrade the harbor cluster instance to harbor v2.4.1.
+If you want to upgrade the harbor cluster from v2.5.0 to v2.5.1, just edit the manifest of the harbor cluster by `kubectl` and set the `version` field from `2.5.0` to `2.5.1` and the harbor operator will upgrade the harbor cluster instance to harbor v2.5.1.
 
 ## 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.4.0`) in the spec.
+1. Edit the manifest of the harbor cluster by `kubectl` and set the `version` field to the newer Harbor version (e.g:`2.5.0`) in the spec.
 
    ```bash
    kubectl -n harbor-cluster-ns edit harborclusters cluster-name
    ```
 
-1. The harbor operator will get an update event of the harbor cluster resource and reconcile to upgrade the harbor cluster to v2.4.0.
+1. The harbor operator will get an update event of the harbor cluster resource and reconcile to upgrade the harbor cluster to v2.5.0.

docs/installation/by-helm-chart.md

@@ -35,25 +35,25 @@ There are several ways to get the Harbor operator helm chart:
     ```shell
     git clone https://github.com/goharbor/harbor-operator.git && \
     cd harbor-operator && \
-    git checkout release-1.2.0 && \
-    make helm-generate RELEASE_VERSION=v1.2.0
+    git checkout release-1.3.0 && \
+    make helm-generate RELEASE_VERSION=v1.3.0
 
     # Checkout to the specified branch or the specified tag
-    # To branch: git checkout <branch-name> e.g.: git checkout release-1.2.0
-    # To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.2.0 -b tag-v1.2.0
+    # To branch: git checkout <branch-name> e.g.: git checkout release-1.3.0
+    # To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.3.0 -b tag-v1.3.0
 
-    # chart is generated to `charts/harbor-operator-v1.2.0.tgz`
+    # chart is generated to `charts/harbor-operator-v1.3.0.tgz`
     ```
 
 ## Deploy Harbor operator with chart
 
-> Under the restriction of helm chart upgrades, CRDs should be updated manually before the deployment of the Harbor operator when the older version(`<v1.2.0`) helm chart has been deployed.
+> Under the restriction of helm chart upgrades, CRDs should be updated manually before the deployment of the Harbor operator when the older version(`<v1.3.0`) helm chart has been deployed.
 
 Run the `helm` command to install the harbor operator to your cluster:
 
 ```shell
 # Change chart path depends on how do you get the helm chart.
-helm upgrade --namespace harbor-operator-ns --install harbor-operator charts/harbor-operator-v1.2.0.tgz --set-string image.repository=ghcr.io/goharbor/harbor-operator --set-string image.tag=v1.2.0
+helm upgrade --namespace harbor-operator-ns --install harbor-operator charts/harbor-operator-v1.3.0.tgz --set-string image.repository=ghcr.io/goharbor/harbor-operator --set-string image.tag=v1.3.0
 ```
 
 For what settings you can override with `--set`, `--set-string`, `--set-file` or `--values`, you can refer to the [values.yaml](../../charts/harbor-operator/values.yaml) file.

docs/installation/enable_minio_console.md

@@ -18,8 +18,8 @@ First, clone the code from the `harbor-operator` repository.
 git clone https://github.com/goharbor/harbor-operator.git
 
 # Checkout to the specified branch or the specified tag.
-# To branch: git checkout <branch-name> e.g.: git checkout release-1.2.0
-# To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.2.0 -b tag-v1.2.0
+# To branch: git checkout <branch-name> e.g.: git checkout release-1.3.0
+# To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.3.0 -b tag-v1.3.0
 ```
 
 Then open the [all-in-one](./kustomization-all-in-one.md) kustomization manifest and locate the `patchesStrategicMerge` section. Comment the patch `- patch/delete-minio-console.yaml`.

docs/installation/kustomization-all-in-one.md

@@ -21,7 +21,7 @@ Directly apply the all-in-one deployment manifest to your Kubernetes cluster:
 kubectl apply -f https://raw.githubusercontent.com/goharbor/harbor-operator/master/manifests/cluster/deployment.yaml
 ```
 
->NOTES: Here we use the deployment manifest in the `main` branch as an example, for deploying the released versions, you can get the deployment manifest in the GitHub release page or find it in the corresponding code branch such as `release-1.2.0`.
+>NOTES: Here we use the deployment manifest in the `main` branch as an example, for deploying the released versions, you can get the deployment manifest in the GitHub release page or find it in the corresponding code branch such as `release-1.3.0`.
 
 Check the installed operators:
 
@@ -47,8 +47,8 @@ If you want to customize the deployment manifest like editing image settings of
 git clone https://github.com/goharbor/harbor-operator.git
 
 # Checkout to the specified branch or the specified tag.
-# To branch: git checkout <branch-name> e.g.: git checkout release-1.2.0
-# To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.2.0 -b tag-v1.2.0
+# To branch: git checkout <branch-name> e.g.: git checkout release-1.3.0
+# To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.3.0 -b tag-v1.3.0
 ```
 
 As the resource manifests are not stored in the codebase, then you need to run the following command to generate the related resource manifests before using `kustomize` to build your customized operator deployment manifest:

docs/installation/kustomization-custom.md

@@ -133,8 +133,8 @@ Of course, you can clone the codebase into your computer and then customize and
 git clone https://github.com/goharbor/harbor-operator.git
 
 # Checkout to the specified branch or the specified tag.
-# To branch: git checkout <branch-name> e.g.: git checkout release-1.2.0
-# To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.2.0 -b tag-v1.2.0
+# To branch: git checkout <branch-name> e.g.: git checkout release-1.3.0
+# To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.3.0 -b tag-v1.3.0
 
 # As the resource manifests are not stored in the codebase, then you need to run the following command to generate the related resource manifests before using `kustomize` to build your customized operator deployment manifest:
 make manifests
@@ -146,7 +146,7 @@ kustomize build manifests/harbor | kubectl apply -f -
 ## kustomize build manifests/harbor | kubectl delete -f -
 ```
 
->NOTES: Here we use the deployment manifest in the `main` branch as an example, for deploying the released versions,you can get the deployment manifest in the GitHub release page or find it in the corresponding code branch such as `release-1.2.0`.
+>NOTES: Here we use the deployment manifest in the `main` branch as an example, for deploying the released versions,you can get the deployment manifest in the GitHub release page or find it in the corresponding code branch such as `release-1.3.0`.
 
 ## What's next
 

docs/makefile.md

@@ -10,8 +10,8 @@ Clone the harbor operator codebase into your computer with command
 git clone https://github.com/goharbor/harbor-operator.git
 
 # Checkout to the specified branch or the specified tag.
-# To branch: git checkout <branch-name> e.g.: git checkout release-1.2.0
-# To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.2.0 -b tag-v1.2.0
+# To branch: git checkout <branch-name> e.g.: git checkout release-1.3.0
+# To tag: git checkout tags/<tag> -b <branch-name> e.g: git checkout tags/v1.3.0 -b tag-v1.3.0
 ```
 
 The `Makefile` is in the root dir of the code repository.