Skip to main content

Release policy

Release semantics​

The Pulsar project follows a variant of Semantic Versioning (semver), which 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.

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 an 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 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,

  • 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 frequencyActive SupportSecurity Support
LTS releaseEvery 18 months24 months36 months
Feature releaseEvery 3 months6 months6 months
Patch releaseWhen it is readyN/AN/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​

VersionReleasedActive SupportSecurity SupportLatest
3.17 months ago
(10 Aug 2023)
Ended 18 days ago
(10 Feb 2024)
Ended 18 days ago
(10 Feb 2024)
3.1.2
3.0 (LTS)10 months ago
(02 May 2023)
End in a year
(02 May 2025)
End in 2 years
(02 May 2026)
3.0.2
(03 Dec 2023)
2.11a year ago
(11 Jan 2023)
Ended 2 months ago
(11 Jan 2024)
Ended 2 months ago
(11 Jan 2024)
2.11.3
2.102 years ago
(18 Apr 2022)
Ended 10 months ago
(18 Apr 2023)
Ended 10 months ago
(18 Apr 2023)
2.10.5
2.92 years ago
(20 Dec 2021)
Ended a year ago
(20 Dec 2022)
Ended a year ago
(20 Dec 2022)
2.9.5
2.83 years ago
(15 Jun 2021)
Ended 2 years ago
(15 Jun 2022)
Ended 2 years ago
(15 Jun 2022)
2.8.4
2.73 years ago
(03 Dec 2020)
Ended 2 years ago
(03 Dec 2021)
Ended 2 years ago
(03 Dec 2021)
2.7.5
2.64 years ago
(17 Jun 2020)
Ended 3 years ago
(17 Jun 2021)
Ended 3 years ago
(17 Jun 2021)
2.6.4
2.54 years ago
(15 Jan 2020)
Ended 3 years ago
(15 Jan 2021)
Ended 3 years ago
(15 Jan 2021)
2.5.2

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.

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.

  1. At the moment of the code freeze, the RM will start preparing a release candidate (RC) following the release process. Committers, contributors, and users will test this RC 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.

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
Was this helpful?