This is an automated email from the ASF dual-hosted git repository.
lhotari pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/pulsar-site.git
The following commit(s) were added to refs/heads/main by this push:
new de675d4e0ea7 Clarify the release policy
de675d4e0ea7 is described below
commit de675d4e0ea7fd1225bb98c20d4eab9ad0d3f88d
Author: Lari Hotari <[email protected]>
AuthorDate: Fri Sep 27 08:40:22 2024 +0300
Clarify the release policy
- based on mailing list discussions:
- https://lists.apache.org/thread/qy8xp2ht0htvctlx2cwgrq2ppnjcp4m3
- https://lists.apache.org/thread/b9mojx7277kpxwrkb9z0xz0g0jnn6n1h
Clarify the LTS release process in the release policy
---
contribute/release-policy.md | 45 ++++++++++++++++----------------
contribute/validate-release-candidate.md | 2 +-
2 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/contribute/release-policy.md b/contribute/release-policy.md
index 7bf7fead74f9..32b37a4bcba7 100644
--- a/contribute/release-policy.md
+++ b/contribute/release-policy.md
@@ -5,7 +5,9 @@ title: Release policy
## Supported Versions
-Please plan your Pulsar deployment updates according to the dates provided
below. However, note that the Apache Pulsar project may provide ad hoc releases
for some older patch versions, depending on resource availability, time
constraints, or the severity of an issue, such as a significant CVE. These
releases would be provided on a 'best-effort' basis. For supported versions,
the Apache Pulsar project follows the [Security policy](/security).
+Please plan your Pulsar deployment updates according to the dates provided
below. The Apache Pulsar project doesn't make separate announcements for
end-of-support or end-of-life. However, note that the Apache Pulsar project may
provide ad hoc releases for some older patch versions, depending on resource
availability, time constraints, or the severity of an issue, such as a
significant CVE. These releases would be provided on a 'best-effort' basis. For
supported versions, the Apache Pulsa [...]
+
+The Apache Pulsar project accepts [issue
reports](https://github.com/apache/pulsar/issues) for supported versions. Issue
reporters are requested to upgrade to a supported version for both Pulsar
clients and Pulsar clusters before filing issue reports. Commercial vendors
around Apache Pulsar may offer paid options for users requiring security and
bug fix support for previous release versions.
````mdx-code-block
import SupportedVersionsTable from
"@site/src/components/SupportedVersionsTable";
@@ -15,9 +17,9 @@ import SupportedVersionsTable from
"@site/src/components/SupportedVersionsTable"
## Release semantics
-The Pulsar project follows a variant of Semantic Versioning (semver), which
replacing `major.minor.patch` with `LTS.feature.patch`.
+The Pulsar project follows a variant of Semantic Versioning (semver),
replacing `major.minor.patch` with `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.
+Concretely, existing releases can expect patches for bugs and security
vulnerabilities. New features will target 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 will simply signal a new
long-term support (LTS) release.
For example,
@@ -33,11 +35,11 @@ For example,
## Compatibility between releases
-When upgrading an existing cluster, it is important to upgrade components
linearly.
+When upgrading an existing cluster, it is important to upgrade components
linearly. The reason for this is that changes in releases are designed in a way
that allows upgrading an existing Pulsar cluster to a newer release and then
rolling back to the original release version. This is considered when changes
are made in Pulsar and the default BookKeeper configuration for Pulsar. Since
Apache Pulsar is an open-source project, there is no guarantee. Each Pulsar
user is responsible for opera [...]
-Before 3.0, upgrade should be done linearly through each feature version. For
example, when upgrading from 2.8 to 2.10, it is important to upgrade to 2.9
before going to 2.10.
+Before version 3.0, the upgrade should be done linearly through each feature
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,
+Starting from version 3.0, live upgrade/downgrade between one LTS and the next
one is supported. For example,
* 3.0 -> 4.0 -> 3.0 is OK;
* 3.2 -> 4.0 -> 3.2 is OK;
@@ -63,31 +65,30 @@ Therefore, users can choose between stay in an LTS release
until they are ready
## Release cycles
-Generally, one committer shall volunteer as the release manager (RM) for a
specific release.
+Generally, one committer shall volunteer as the release manager for a specific
release. A release is initiated with a discussion thread on the Pulsar mailing
list.
-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.
+As part of the release discussion thread, a timeline is decided upon for the
release. The release manager will drive this discussion, and decisions will be
made in the Apache way.
-From the code-freeze point, to minimize the risk of delaying the release, only
bug fixes involving a regression of behavior compared to a previous release
should be allowed. Occasional exceptions will be possible after higher scrutiny
of the change.
+For feature releases and LTS releases, the last three weeks of the release
cycle will be marked as a releasing period to finish the pending changes and
decide on what features (PIP implementations) go into the release version.
-1. At the moment of the code freeze, the RM will start preparing a release
candidate (RC) following the [release process](release-process.md). Committers,
contributors, and users will [test this RC](validate-release-candidate.md) to
detect issues as early as possible. (A formal vote by the PMC will not be
required at this stage, though any disagreement should be sent out ASAP).
-2. After 1 week, if there are any changes, the RM will provide a new RC
release that the community will test again.
-3. After 1 more week, if there are any changes, a third RC will be prepared,
and this will be submitted to vote to the PMC. Otherwise, the vote will be held
on an earlier RC if no issues are found.
-4. The last 1 week will be used for the voting process and for updating Pulsar
website and the blog post announcing the release, which should (hopefully)
happen on the scheduled day.
+As part of this period for an LTS or feature release, there could be multiple
preview releases and multiple release candidates. A preview release is one that
is not intended to be released. The purpose of the preview release is to allow
users to start testing the new release functionality by making the release
binaries available. The preview release will contain a suffix `-pre.1`,
`-pre.2`. Preview releases don't apply to patch releases.
-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".
+Here's an example of the 4.0.0 LTS release timeline:
-:::note
+* 2024-09-26 - Target publishing date for 4.0 preview 1 (4.0.0-pre.1)
+* 2024-10-03 - Target publishing date for 4.0 preview 2 (4.0.0-pre.2)
+* 2024-10-07 - Code freeze for 4.0 by branching branch-4.0 from the master
branch
+* 2024-10-10 - Target publishing date for 4.0 release candidate 1
+* 2024-10-15 - Reserved for 4.0 release candidate 2 if needed
+* 2024-10-17 - Announcement date for 4.0.0
-For example, the next release of Pulsar is 3.0.0, and it has the planned
timeline as:
+The LTS or feature release timeline will also note the target date for
branching the release branch off the master branch. After that point in time,
the release manager will coordinate the changes that will be included in the
release branch. The intention is to minimize the risk of delaying the release
and only include bug fixes involving a regression of behavior compared to a
previous release or critical improvements to the new features (PIP
implementations) that are part of the release.
-* 2023-04-11 - RC-1
-* 2023-04-18 - RC-2
-* 2023-04-25 - RC-3
-* 2023-05-02 - Announce 3.0 Release
+For patch releases, the process is similar, but there is no branching off the
master branch since the release branch already exists. The patch release
doesn't contain preview releases.
-:::
+The preparation of releases is handled according to the [release
process](release-process.md). The release manager is responsible for updating
the process documentation when there's a need to adapt the process. There's
also a guide for [release validation](validate-release-candidate.md) which is
used by Pulsar contributors before voting on releases. Before releases are
announced, the release will be voted upon on the [Pulsar dev mailing
list](https://lists.apache.org/list.html?dev@pulsar [...]
## Related PIPs
* [PIP-47: A Time-Based Release
Plan](https://github.com/apache/pulsar/wiki/PIP-47%3A-Time-Based-Release-Plan)
-* [PIP-175: Extend time based release
process](https://github.com/apache/pulsar/issues/15966)
+* [PIP-175: Extend time based release
process](https://github.com/apache/pulsar/issues/15966)
\ No newline at end of file
diff --git a/contribute/validate-release-candidate.md
b/contribute/validate-release-candidate.md
index 19e8b7b993c8..0dbcfb62ec5d 100644
--- a/contribute/validate-release-candidate.md
+++ b/contribute/validate-release-candidate.md
@@ -1,6 +1,6 @@
---
id: validate-release-candidate
-title: Verifying release candidates
+title: Validating release candidates
---
This page contains manual instructions for reviewing and verifying a release
candidate.
