You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by "tisonkun (via GitHub)" <gi...@apache.org> on 2023/02/22 13:50:31 UTC
[GitHub] [pulsar-site] tisonkun opened a new pull request, #433: [improve][doc] Release policy and matrix
tisonkun opened a new pull request, #433:
URL: https://github.com/apache/pulsar-site/pull/433
This closes https://github.com/apache/pulsar/issues/19570.
### Documentation
<!-- DO NOT REMOVE THIS SECTION. CHECK THE PROPER BOX ONLY. -->
- [x] `doc` <!-- Your PR contains doc changes. Please attach the local preview screenshots (run `./preview.sh` at root path) to your PR description, or else your PR might not get merged. -->
- [ ] `doc-required` <!-- Your PR changes impact docs and you will update later -->
- [ ] `doc-not-needed` <!-- Your PR changes do not impact docs -->
- [ ] `doc-complete` <!-- Docs have been already added -->
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1118344821
##########
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:
When we use `marjor.minor.patch` concept, it's the minor.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1119569802
##########
contribute/release-policy.md:
##########
@@ -0,0 +1,84 @@
+---
+id: release-policy
+title: Release policy
+---
+
+## Release semantics
Review Comment:
I lower the relation to semver. Please see the latest commit f29a51cc9178f8a02acf5eb9d99d56e1c19abb1a
##########
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:
Updated.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] momo-jun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "momo-jun (via GitHub)" <gi...@apache.org>.
momo-jun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1119663761
##########
contribute/release-policy.md:
##########
@@ -0,0 +1,89 @@
+---
+id: release-policy
+title: Release policy
+---
+
+## Release semantics
+
+The Pulsar project follows a variant of Semantic Versioning (semver), which mapping `z.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;
+* 4.0.0 is a LTS release.
Review Comment:
```suggestion
* 4.0.0 is an LTS release.
```
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] momo-jun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "momo-jun (via GitHub)" <gi...@apache.org>.
momo-jun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1115173416
##########
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;
+* 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.
Review Comment:
`Before 3.0, upgrade should be done linearly through each minor version.` - ditto
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] Anonymitaet commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "Anonymitaet (via GitHub)" <gi...@apache.org>.
Anonymitaet commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1115157781
##########
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:
➕1 on showing the TODOs because it's a way to demonstrate the community is thinking about the future directions and has a plan on it. The positive influence is more than negative effect (fail to hit the DDL).
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1115543505
##########
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 |
Review Comment:
Finished.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1114359849
##########
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 hesitate about publishing these TODOs since it should be continuously updated manually and it's quite an ideal case - I'm afraid that we will almost break the "promised" timeline.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1119754477
##########
contribute/release-policy.md:
##########
@@ -0,0 +1,89 @@
+---
+id: release-policy
+title: Release policy
+---
+
+## Release semantics
+
+The Pulsar project follows a variant of Semantic Versioning (semver), which mapping `z.minor.patch` to `LTS.feature.patch`.
Review Comment:
```suggestion
The Pulsar project follows a variant of Semantic Versioning (semver), which replacing `major.minor.patch` with `LTS.feature.patch`.
```
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1119569802
##########
contribute/release-policy.md:
##########
@@ -0,0 +1,84 @@
+---
+id: release-policy
+title: Release policy
+---
+
+## Release semantics
Review Comment:
I lower the relation to semver. Please see the latest commit fc4a92c78b26dff376b3fd27fefd1ec0d29527e1
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] codelipenghui commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "codelipenghui (via GitHub)" <gi...@apache.org>.
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1114357062
##########
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 |
Review Comment:
This table is possibly to be data-driven, perhaps by `data/release-pulsar.js`.
I'm investigating for doing it programatically, but leave it as is for the first review so that we know what it basically looks like.
The final result should be as https://endoflife.date/python where:
1. Distinguish supported/unsupported versions by color.
2. Calculate the time interval.
3. Link to release notes.
4. Del line for unsupported versions.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1119485852
##########
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:
Please take a look at:
* https://github.com/apache/pulsar-site/pull/433#discussion_r1115172798
* https://github.com/apache/pulsar-site/pull/433#issuecomment-1441130956
I can update all the occurrences but we need some consensus first.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] Anonymitaet commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "Anonymitaet (via GitHub)" <gi...@apache.org>.
Anonymitaet commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1119466140
##########
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:
Change to "major/minor" to keep consistent? Can you check all the occurencies in the whole doc?
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1116447702
##########
contribute/release-process.md:
##########
@@ -71,7 +71,7 @@ If you created a new branch, update the [CI - OWASP Dependency Check](https://gi
Note that you should also stop the workflow for previous Pulsar versions that are EOL.
-Also, if you created a new branch, please update the "Supported Versions" table on the [version policy](version-policy.md) page. This table is for support timelines based on when minor releases take place.
+Also, if you created a new branch, please update the "Supported Versions" table on the [release policy](release-policy.md) page. This table is for support timelines based on when minor releases take place.
Review Comment:
It's now data-driven so the step updating `data/release-pulsar.js` should cover this requirement. I'll update the doc.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] Anonymitaet commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "Anonymitaet (via GitHub)" <gi...@apache.org>.
Anonymitaet commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1116419217
##########
contribute/release-process.md:
##########
@@ -71,7 +71,7 @@ If you created a new branch, update the [CI - OWASP Dependency Check](https://gi
Note that you should also stop the workflow for previous Pulsar versions that are EOL.
-Also, if you created a new branch, please update the "Supported Versions" table on the [version policy](version-policy.md) page. This table is for support timelines based on when minor releases take place.
+Also, if you created a new branch, please update the "Supported Versions" table on the [release policy](release-policy.md) page. This table is for support timelines based on when minor releases take place.
Review Comment:
Do we need to add instructions on how to update the "Supported Versions" table?
##########
contribute/release-policy.md:
##########
@@ -0,0 +1,89 @@
+---
+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
Review Comment:
Suggest re-organize this part to "steps" (which can be based on "time" or "task category" and add a flowchart to indicate the process more clearly.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1119535696
##########
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:
I'll read it as remove the RoadMap part but use 3.0.0 as an example for the release cycle section.
##########
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:
SGTM.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] merlimat merged pull request #433: [improve][doc] Release policy and matrix
Posted by "merlimat (via GitHub)" <gi...@apache.org>.
merlimat merged PR #433:
URL: https://github.com/apache/pulsar-site/pull/433
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1118359745
##########
contribute/release-process.md:
##########
@@ -71,7 +71,7 @@ If you created a new branch, update the [CI - OWASP Dependency Check](https://gi
Note that you should also stop the workflow for previous Pulsar versions that are EOL.
-Also, if you created a new branch, please update the "Supported Versions" table on the [version policy](version-policy.md) page. This table is for support timelines based on when minor releases take place.
+Also, if you created a new branch, please update the "Supported Versions" table on the [release policy](release-policy.md) page. This table is for support timelines based on when minor releases take place.
Review Comment:
Fixed by 88734f1d8af2b6a9d913452d996dc124a6a3de7e
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1118360138
##########
contribute/release-policy.md:
##########
@@ -0,0 +1,89 @@
+---
+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
Review Comment:
Fixed by 3613ed52d6835479472a7281b70e949fc06f58f7.
A flowchart may be made later.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] momo-jun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "momo-jun (via GitHub)" <gi...@apache.org>.
momo-jun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1115172798
##########
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:
We need to align on the wording and consistently use it throughout the doc site.
@codelipenghui and @BewareMyPower mentioned there was no `patch release` term for Pulsar, so we named it `minor` in contrast to `major` in the release process doc. If we decide to go with `feature/patch`, better eliminate `major/minor` to avoid confusing and guessing.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1119536112
##########
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:
Sounds reasonable. Let me try to reword it.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#issuecomment-1447569990
Comments resolved as fc4a92c78b26dff376b3fd27fefd1ec0d29527e1. Please take a look.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#issuecomment-1447804501
@codelipenghui @merlimat @eolivelli @dave2wave
Given the content is based on a voted proposal (PIP-175), I'm going to merge it tomorrow if no more comments.
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] momo-jun commented on a diff in pull request #433: [improve][doc] Release policy and matrix
Posted by "momo-jun (via GitHub)" <gi...@apache.org>.
momo-jun commented on code in PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#discussion_r1115173243
##########
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:
`New features will target minor releases.` ---- I guess it refers to "major", like 2.10?
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [pulsar-site] tisonkun commented on pull request #433: [improve][doc] Release policy and matrix
Posted by "tisonkun (via GitHub)" <gi...@apache.org>.
tisonkun commented on PR #433:
URL: https://github.com/apache/pulsar-site/pull/433#issuecomment-1441130956
Good catch, @momo-jun!
Since we now have LTS release, calling regular release a "major release" sounds weird. I may prefer to second semver definition major/minor/patch, which is wide use and thus easy to understand, while our major version bump only denotes a new LTS release.
I'd like to postpone the change until we have a consensus on the glossary. All occuranaces are counted.
cc @merlimat @codelipenghui @michaeljmarshall
--
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: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org