codelipenghui commented on code in PR #433: URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1119495195
########## contribute/release-policy.md: ########## @@ -0,0 +1,84 @@ +--- +id: release-policy +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. + +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.1.0 is a feature release; +* 3.2.0 is a feature release; +* 3.2.1 is a patch release; +* 4.0.0 is a LTS release. + +## Compatibility between releases + +When upgrading an existing cluster, it is important to upgrade components linearly. + +Before 3.0, upgrade should be done linearly through each minor version. For example, when upgrading from 2.8 to 2.10, it is important to upgrade to 2.9 before going to 2.10. + +Starting from 3.0, additionally, live upgrade/downgrade between one LTS and the next one is guaranteed. For example, + +* 3.0 -> 4.0 -> 3.0 is OK; +* 3.2 -> 4.0 -> 3.2 is OK; +* 3.2 -> 4.4 -> 3.2 is OK; +* 3.2 -> 5.0 is _not_ OK. + +## Release frequency and support expectation + +| | Release frequency | Active Support | Security Support | +|-----------------|-------------------|----------------|------------------| +| LTS release | Every 18 months | 24 months | 36 months | +| Feature release | Every 3 months | 6 months | 6 months | +| Patch release | When it is ready | N/A | N/A | + +This can be translated into: + +* The last 2 LTS releases and the last 2 feature releases are supported. +* Security patches are provided for the past 3 LTS releases and 2 feature releases + +Therefore, users can choose between stay in an LTS release until they are ready to jump into the next LTS, or try the latest releases which contains required features. + +## Supported Versions + +````mdx-code-block +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. + +For feature releases and LTS releases, the last 3 weeks of the release cycle will be marked as a code-freeze period. The RM will branch off from master, and the RM is also responsible for selecting the changes that will be cherry-picked in the release branch. + Review Comment: Move them ``` * 2023-04-11 - RC-1 * 2023-04-18 - RC-2 * 2023-04-25 - RC-3 * 2023-05-02 - Announce 3.0 Release ``` here looks better. ########## contribute/release-policy.md: ########## @@ -0,0 +1,84 @@ +--- +id: release-policy +title: Release policy +--- + +## Release semantics Review Comment: Should it be semantic version? ########## contribute/release-policy.md: ########## @@ -0,0 +1,94 @@ +--- +id: release-policy +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. Review Comment: We don't strictly follow the semver spec. We should not introduce incompatible APIs from 3.0.0 to 4.0.0 The LTS version is for stability since we will have many feature and patch releases before bumping a new LTS version. IMO, we should use LTS, feature, and patch releases in the feature. The major release and minor release is confusing. And the patch release can also happen on a LTS version, like 3.0.1, 3.0.2. ########## contribute/release-policy.md: ########## @@ -0,0 +1,84 @@ +--- +id: release-policy +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. + +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.1.0 is a feature release; +* 3.2.0 is a feature release; +* 3.2.1 is a patch release; Review Comment: We should also add `3.0.1 is the a patch release of the LTS version` ########## contribute/release-policy.md: ########## @@ -0,0 +1,94 @@ +--- +id: release-policy +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. + +For example, + +* 2.10.0 is a feature release; +* 2.10.1 is a patch release; Review Comment: Yes, before, we only used major release and minor release. Actually, major release == feature release, minor release == patch release. +1 to go to feature and patch release. ########## contribute/release-policy.md: ########## @@ -0,0 +1,93 @@ +--- +id: release-policy +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. + +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.1.0 is a feature release; +* 3.2.0 is a feature release; +* 3.2.1 is a patch release; +* 4.0.0 is a LTS release. + +## Compatibility between releases + +When upgrading an existing cluster, it is important to upgrade components linearly. + +Before 3.0, upgrade should be done linearly through each minor version. For example, when upgrading from 2.8 to 2.10, it is important to upgrade to 2.9 before going to 2.10. + +Starting from 3.0, additionally, live upgrade/downgrade between one LTS and the next one is guaranteed. For example, + +* 3.0 -> 4.0 -> 3.0 is OK; +* 3.2 -> 4.0 -> 3.2 is OK; +* 3.2 -> 4.4 -> 3.2 is OK; +* 3.2 -> 5.0 is _not_ OK. + +## Release frequency and support expectation + +| | Release frequency | Active Support | Security Support | +|-----------------|-------------------|----------------|------------------| +| LTS release | Every 18 months | 24 months | 36 months | +| Feature release | Every 3 months | 6 months | 6 months | +| Patch release | When it is ready | N/A | N/A | + +This can be translated into: + +* The last 2 LTS releases and the last 2 feature releases are supported. +* Security patches are provided for the past 3 LTS releases and 2 feature releases + +Therefore, users can choose between stay in an LTS release until they are ready to jump into the next LTS, or try the latest releases which contains required features. + +## Supported Versions + +| Version | Released | Active Support | Security Support | Latest | +|---------|---------------|-----------------|------------------|--------| +| 2.10 | April 2022 | April 2023 | April 2023 | 2.10.3 | +| 2.9 | November 2021 | November 2022 | November 2022 | 2.9.4 | +| 2.8 | June 2021 | June 2022 | June 2022 | 2.8.4 | +| 2.7 | November 2020 | November 2021 | November 2021 | 2.7.5 | +| 2.6 | June 2020 | June 2021 | June 2021 | 2.6.4 | +| 2.5 | January 2020 | January 2021 | January 2021 | 2.5.2 | +| 2.4 | July 2019 | July 2020 | July 2020 | 2.4.2 | + +## 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 Review Comment: I think we don't need to add RC-1, RC-2 here. It only for the internal release process. The documentation will be available for all users. So it's better to keep it simple, the next release 3.0.0 will available in 2023-05-02 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
