Addres comments

Signed-off-by: tison <wander4096@gmail.com>

Author: tisonkun

contribute/release-policy.md

@@ -5,14 +5,17 @@ title: Release policy
 
 ## Release semantics
 
-The Pulsar project follows a variant of [Semantic Versioning](http://semver.org/spec/v2.0.0.html). Existing releases can expect patches for bugs and security vulnerabilities. New features will target minor releases. The difference is that a major version bump will not carry any special meaning in terms of "big features" included in the release or breaking API changes. Instead, it would simply signal a new long-term support (LTS) release.
+The Pulsar project follows a variant of Semantic Versioning (semver), which mapping `major.minor.patch` to `LTS.feature.patch`.
+
+Concretely, existing releases can expect patches for bugs and security vulnerabilities. New features will target to feature releases. A "major" version bump will not carry any special meaning in terms of "big features" included in the release or breaking API changes. Instead, it would simply signal a new long-term support (LTS) release.
 
 For example,
 
 * 2.10.0 is a feature release;
 * 2.10.1 is a patch release;
 * 2.11.0 is a feature release;
 * 3.0.0 is the first LTS release;
+* 3.0.1 is a patch release of the LTS release;
 * 3.1.0 is a feature release;
 * 3.2.0 is a feature release;
 * 3.2.1 is a patch release;
@@ -54,15 +57,6 @@ import SupportedVersionsTable from "@site/src/components/SupportedVersionsTable"
 <SupportedVersionsTable />
 ````
 
-## Roadmap for release plans
-
-The next release of Pulsar is 3.0.0, and it has the planned timeline as:
-
-* 2023-04-11 - RC-1
-* 2023-04-18 - RC-2
-* 2023-04-25 - RC-3
-* 2023-05-02 - Announce 3.0 Release
-
 ## Release cycles
 
 Generally, one committer shall volunteer as the release manager (RM) for a specific release.
@@ -78,6 +72,17 @@ From the code-freeze point, to minimize the risk of delaying the release, only b
 
 For patch releases, the process is the same while there is no code-freeze period and strict timeline. Basically, patch release is out "when it is ready".
 
+:::note
+
+For example, the next release of Pulsar is 3.0.0, and it has the planned timeline as:
+
+* 2023-04-11 - RC-1
+* 2023-04-18 - RC-2
+* 2023-04-25 - RC-3
+* 2023-05-02 - Announce 3.0 Release
+
+:::
+
 ## Related PIPs
 
 * [PIP-47: A Time-Based Release Plan](https://github.com/apache/pulsar/wiki/PIP-47%3A-Time-Based-Release-Plan)

contribute/release-process.md

@@ -5,18 +5,18 @@ title: Release process
 
 This page contains instructions for Pulsar committers on how to perform a release.
 
-The term major/minor releases used throughout this document is defined as follows:
+The term feature/patch releases used throughout this document is defined as follows:
 
-* Major releases refer to feature releases, such as 2.10.0, 2.11.0, and so on.
-* Minor releases refer to bug-fix releases, such as 2.10.1, 2.10.2, and so on.
+* Feature releases contain 2.10.0, 2.11.0, 3.0.0, and so on.
+* Patch releases refer to bug-fix releases, such as 2.10.1, 2.10.2, and so on.
 
 ## Preparation
 
 Open a discussion on dev@pulsar.apache.org to notify others that you volunteer to be the release manager of a specific release. If there are no disagreements, you can start the release process.
 
-For major releases, you should create a new branch named `branch-X.Y` once all PRs with the X.Y.0 milestone are merged. If some PRs with the X.Y.0 milestone are still working in progress and might take much time to complete, you can move them to the next milestone if they are not important. In this case, you'd better notify the author in the PR.
+For feature releases, you should create a new branch named `branch-X.Y` once all PRs with the X.Y.0 milestone are merged. If some PRs with the X.Y.0 milestone are still working in progress and might take much time to complete, you can move them to the next milestone if they are not important. In this case, you'd better notify the author in the PR.
 
-For minor releases, if there are no disagreements, you should cherry-pick all merged PRs labeled with `release/X.Y.Z` into `branch-X.Y`. After these PRs are cherry-picked, you should add the `cherry-picked/branch-X.Y` labels.
+For patch releases, if there are no disagreements, you should cherry-pick all merged PRs labeled with `release/X.Y.Z` into `branch-X.Y`. After these PRs are cherry-picked, you should add the `cherry-picked/branch-X.Y` labels.
 
 Sometimes some PRs cannot be cherry-picked cleanly, you might need to create a separate PR and move the `release/X.Y.Z` label from the original PR to it. In this case, you can ask the author to help create the new PR.
 
@@ -46,7 +46,7 @@ Also, you need to **clean up the bookkeeper's local compiled** to make sure the
 
 We are going to create a branch from `master` to `branch-v2.X` where the tag will be generated and where new fixes will be applied as part of the maintenance for the release.
 
-The branch needs only to be created for major releases, and not for minor releases like `2.3.1`. For minor releases, go to the next step.
+The branch needs only to be created for feature releases, and not for patch releases like `2.3.1`. For patch releases, go to the next step.
 
 For example, when you create the `v2.3.0` release, the branch `branch-2.3` will be created; but for `v2.3.1`, we
 keep using the old `branch-2.3`.
@@ -101,7 +101,7 @@ git push origin branch-2.X
 git push origin v2.X.0-candidate-1
 ```
 
-For minor releases, the tag is like `2.3.1`.
+For patch releases, the tag is like `2.3.1`.
 
 ### Build release artifacts
 
@@ -347,7 +347,7 @@ If you don't have the permission, you can ask someone with access to apachepulsa
 
 :::caution
 
-This step can be skipped if the major version number is not the latest.
+This step is for the latest release only.
 
 :::
 
@@ -450,7 +450,7 @@ Read more on the manual of [pytools](https://github.com/apache/pulsar-site/tree/
 
 :::caution
 
-This step is for major releases only, unless you're sure that significant Javadoc fixes are made against the minor release.
+This step is for feature releases only, unless you're sure that significant Javadoc fixes are made against the patch release.
 
 :::
 
@@ -474,7 +474,7 @@ Read more on the manual of [pytools](https://github.com/apache/pulsar-site/tree/
 
 :::caution
 
-This step is for major releases only, unless you're sure that significant reference fixes are made against the minor release.
+This step is for feature releases only, unless you're sure that significant reference fixes are made against the patch release.
 
 :::
 
@@ -495,7 +495,7 @@ Read more on the manual of [pytools](https://github.com/apache/pulsar-site/tree/
 
 :::caution
 
-This step is for major releases only, unless you're sure that significant doc fixes are made against the minor release.
+This step is for feature releases only, unless you're sure that significant doc fixes are made against the patch release.
 
 :::
 
@@ -515,7 +515,7 @@ Read more on the manual of [pytools](https://github.com/apache/pulsar-site/tree/
 
 :::caution
 
-This step is for major releases only, unless you're sure that significant doc fixes are made against the minor release.
+This step is for feature releases only, unless you're sure that significant doc fixes are made against the patch release.
 
 :::
 
@@ -551,7 +551,7 @@ For every release, you should add a `<release-version>` entry to the correspondi
 
 :::caution
 
-The following steps are for major releases only.
+The following steps are for feature releases only.
 
 :::
 
@@ -629,7 +629,7 @@ svn rm https://dist.apache.org/repos/dist/release/pulsar/pulsar-2.Y.0
 
 :::caution
 
-This step is for major releases only.
+This step is for feature releases only.
 
 :::