Merge branch 'master' into add-mapper-docs

README.md

@@ -11,7 +11,7 @@ You write the pages in Markdown, and Docusaurus wraps them up into a website.
 
 - Please see [How to contributing](CONTRIBUTING.md) for instructions on how to contribute, if you are not familiar with the
   GitHub workflow
-- [Start contributing](https://kubeedge.netlify.com/docs/about/contributing/)
+- [Start contributing](https://kubeedge.io/docs/community/contribute)
 
 ## Quick start
 

docs/advanced/debug.md

@@ -7,7 +7,7 @@ sidebar_position: 3
 
 1. Make sure you can find the kubernetes `ca.crt` and `ca.key` files. If you set up your kubernetes cluster by `kubeadm` , those files will be in `/etc/kubernetes/pki/` dir.
 
-    ``` shell
+    ```shell
     ls /etc/kubernetes/pki/
     ```
 
@@ -17,7 +17,7 @@ sidebar_position: 3
     export CLOUDCOREIPS="192.168.0.139"
     ```
     (Warning: the same **terminal** is essential to continue the work, or it is necessary to type this command again.) Checking the environment variable with the following command:
-    ``` shell
+    ```shell
     echo $CLOUDCOREIPS
     ```
 
@@ -45,7 +45,7 @@ sidebar_position: 3
 
     Run the following command on the host on which each apiserver runs:
 
-    **Note:** You need to set the cloudcoreips variable first
+    **Note:** Make sure `CLOUDCOREIPS` environment variable is set
 
     ```bash
     iptables -t nat -A OUTPUT -p tcp --dport 10350 -j DNAT --to $CLOUDCOREIPS:10003
@@ -63,9 +63,11 @@ sidebar_position: 3
 
 ## Update Configurations
 
-1. Modify **both** `/etc/kubeedge/config/cloudcore.yaml` and `/etc/kubeedge/config/edgecore.yaml` on cloudcore and edgecore. Set up **cloudStream** and **edgeStream** to `enable: true`. Change the server IP to the cloudcore IP (the same as $CLOUDCOREIPS).
+1. Update `cloudcore` configuration to enable **cloudStream**.
+
+    If `cloudcore` is installed as binary, you can directly modify `/etc/kubeedge/config/cloudcore.yaml` with using editor.
+    If `cloudcore` is running as kubernetes deployment, you can use `kubectl edit cm -n kubeedge cloudcore` to update `cloudcore`'s ConfigurationMap.
 
-    Modify `/etc/kubeedge/config/cloudcore.yaml`:
     ```yaml
     cloudStream:
       enable: true
@@ -79,8 +81,12 @@ sidebar_position: 3
       tunnelPort: 10004
     ```
 
-    Modify `/etc/kubeedge/config/edgecore.yaml`:
-    ``` yaml
+2. Update `edgecore` configuration to enable **edgeStream**.
+
+    This modification needs to be done all edge system where `edgecore` runs to update `/etc/kubeedge/config/cloudcore.yaml`.
+    Make sure the `server` IP address to the cloudcore IP (the same as $CLOUDCOREIPS).
+
+    ```yaml
     edgeStream:
       enable: true
       handshakeTimeout: 30
@@ -94,14 +100,19 @@ sidebar_position: 3
 
 ## Restart
 
-1. Restart all the cloudcore and edgecore.
+1. Restart all the cloudcore and edgecore to apply the **Stream** configuration.
 
-    At the cloud side:
-    ``` shell
+    If `cloudcore` is installed as binary:
+    ```shell
     sudo systemctl restart cloudcore.service
     ```
 
-    At the edge side:
-    ``` shell
+    or `cloudcore` is running in kubernetes deployment:
+    ```shell
+    kubectl rollout restart deployment -n kubeedge cloudcore
+    ```
+
+    At the all edge side where `edgecore` runs:
+    ```shell
     sudo systemctl restart edgecore.service
     ```

docs/community/release.md

@@ -1,6 +1,44 @@
 ---
-title: Release Manager
+title: Release Management
 sidebar_position: 5
 ---
 
-tbd...
+## KubeEdge Release Cycle
+
+KubeEdge releases currently happen approximately every three months. 
+
+![release cycle](/img/community/release-cycle.png)
+
+The release process can be thought of as having four main phases:
+
+- **Feature Definition (Week 1~2)**
+
+    With ongoing feature definition through the year, some set of items will bubble up as targeting a given release. During the initial two weeks, feature work for the given release is defined in suitable planning artifacts in conjunction with SIG Release Team. Milestone is created adn applied correctly so that SIG Release Team can track enhancements and bugs.
+
+- **Feature Work (Week 3~10)**
+
+    Features Development phase spans form the third week to the tenth week of the release cycle. Community developers actively engage in implementing the planned features and enhancements. Weekly community meetings and each SIG meeting are held to ensure effective coordination and progress tracking.
+
+- **Code Freeze and Bug Fixing (Week 11)**
+
+    Code Freeze starts in week 11. A release branch are created and release cycle enters into the final testing stage. Only bug fixes are accepted into the release codebase during this time. Feature code cannot be merged anymore to ensure stability of the release branch.
+
+- **Release (Week 12)**
+
+  Once the first three phases are comleted, the release branch enters the final stage. The community prepares for the official release by conducting thorough testing and ensuring documentation and release notes are up-to-date. Following this, the final version is officially released and made available for public use.
+
+When the code base is sufficiently stable, the master branch opens for general development and work begins there for the next release milestone. 
+
+## Patch Release
+
+Our typical patch release cadence is monthly. If there are critical issues present in the current version, an expedited release may be necessary.
+
+### Cherry Picks
+
+Any remaining modifications for the current release are cherry picked from master back to the release branch. Cherry picks must be merge-ready in GitHub with proper labels (e.g., approved, lgtm, release-note) and passing CI tests ahead of the patch release deadline.
+
+### Support Versions
+
+We provide maintenance for the latest three releases. This means that bug fixes will be applied to these releases to ensure their stability and reliability. However, in exceptional cases where severe issues arise, we may consider releasing patches for earlier versions as well, based on the specific circumstances.
+
+![release lifecycle](/img/community/release-lifecycle.png)

i18n/zh/docusaurus-plugin-content-docs/current/community/release.md

@@ -2,3 +2,43 @@
 title: 版本管理
 sidebar_position: 5
 ---
+
+## KubeEdge 版本周期
+
+KubeEdge 目前大约每三个月会发布一个版本。
+
+![release cycle](/img/community/release-cycle.png)
+
+发布过程可被认为有四个阶段：
+
+- **特性定义 (第1~2周)**
+
+  根据全年RoadMap，确定当前版本的需求列表。在这两周中，SIG Release 会联合社区用户与开发者共同制定版本需求，规划新版本特性列表。同时Milestone也会被创建并运用起来，来保证SIG Release团队可以跟踪特性与问题修复工作。
+
+- **特性开发 (第3~10周)**
+
+  特性开发阶段从版本周期的第三周延续至第十周。社区开发人员按照计划进行特性开发与问题修复。每周的社区会议和各个SIG会议沟通讨论，确保有效的工作协调和跟踪进度。
+
+- **代码冻结与问题修复 (第11周)**
+
+  第11周开始进行代码冻结。创建版本分支，版本发布周期进入最后的测试阶段。在此阶段只接受bugfix的PR合并到版本分支中。为确保版本分支的稳定性，不再合并特性代码。
+
+- **版本发布 (第12周)**
+
+  完成前三个阶段后，版本进入最后的发布准备阶段。社区通过进行测试、文档和版本Changelog来准备正式发布。随后，最终版本正式发布并可供公众使用。
+
+当代码库足够稳定时，主分支将开放进行开发，并从开始下一个版本的工作。 
+
+## 补丁版本
+
+补丁版本通常是每月发布一次，如果出现严重问题需要修复，社区也会缩短发布周期，尽快发布补丁版本。
+
+### Cherry Picks
+
+当前版本的任何修改都是从 master 分支cherry-pick回版本分支。Cherry-Pick的PR必须在 GitHub 中准备好合并，带有approved和lgtm标签， 并在补丁版本发布截止日期之前通过 CI 测试。
+
+### 支持的版本
+
+通常社区会维护最新三个版本的补丁发布，这意味着问题修复可以合入最新三个版本来保证版本的稳定性与可靠性。如果出现严重问题，社区会根据具体情况考虑对更早的版本发布补丁。
+
+![release lifecycle](/img/community/release-lifecycle.png)