Provides a summary of recent version support end dates and details the RisingWave versioning scheme (SemVer), release cadence, support rules, backporting policy, and deprecation communication.
This document summarizes support end dates for recent RisingWave releases and provides a comprehensive overview of the software release lifecycle, including the versioning scheme, release cadence, and the detailed version support and deprecation policy. It helps users of RisingWave Cloud and the on-premises Premium edition understand how long different versions are supported and plan upgrades accordingly.
This policy focuses on software versions. For the lifecycle and deprecation of individual features, see RisingWave feature lifecycle and deprecation.
The following table summarizes support end dates for recent RisingWave releases. Refer to the detailed policy below for the rules governing these dates.
Future support-end dates will be updated as new versions are released.
Version | Release Date | Support Ends |
---|---|---|
v1.10 | Jul 30, 2024 | Jan 26, 2025 |
v2.0 | Sep 26, 2024 | Feb 11, 2025 |
v2.1 | Dec 7, 2024 | April 14, 2025 |
v2.2 | Feb 11, 2025 | May 22, 2025 |
v2.3 | April 14, 2025 | Upon the release of v2.5 |
v2.4 | May 22, 2025 | Upon the release of v2.6 |
RisingWave adheres to the Semantic Versioning (SemVer) standard, using a three-part numbering system: Major.Minor.Patch
. Understanding this scheme is crucial for interpreting the support policy.
2.0.0
): Represents significant, milestone releases. These releases often introduce substantial new features, architectural changes, and may include breaking changes. Breaking changes might require data migration or adjustments to user workflows.2.1.0
): Represents regular releases with new features, enhancements, and bug fixes.2.1.1
): Represents releases focused solely on bug fixes and security patches. Normally the latest patch version is the recommended version within a minor version.RisingWave aims for a predictable release schedule:
This section defines the rules for discontinuing support for older RisingWave versions. “Support” includes providing bug fixes, security patches, and technical assistance. When support ends, a version is considered deprecated.
3.1 Major version deprecation:
Support for a major version ends 4 months after the release of the subsequent major version.
Example: If RisingWave 3.0.0
is released on September 1st, 2025, then support for all 2.x.x
versions (e.g., 2.10.5
) that have not already been deprecated ends on January 1st, 2026. This provides a 4-month window for users to migrate.
3.2 Minor version deprecation:
3.3 Backporting policy:
Critical bug fixes and security patches are backported to a limited set of supported, non-deprecated versions. This ensures users receive essential updates even if not on the absolute latest version. Fixes are typically applied to:
Example: On March 5th, 2025, assume:
2.3.0
is undergoing release testing.2.2.0
is the latest released version.1.10.0
is from a previous major release but is still supported (within the 4-month window after 2.0.0
was released).In this scenario, critical fixes would be backported to 2.3.0
, 2.2.0
, and potentially 1.10.0
. Backporting to 2.1.0
would generally not occur if 2.3.0
had already been released (based on the minor version deprecation rule).
3.4 Exceptions:
RisingWave communicates version support changes and upcoming deprecations clearly and proactively.
5.1 Communication channels: Information is shared via:
5.2 Content of notifications: Deprecation notices typically include:
5.3 Advance notice:
5.4 Migration support: Where applicable, RisingWave provides tools, documentation (like migration guides), and support resources to assist with upgrades to supported versions.
5.5 Feedback mechanism: User feedback on the deprecation process and migration experience is encouraged through standard channels (e.g., forums, support tickets).
Provides a summary of recent version support end dates and details the RisingWave versioning scheme (SemVer), release cadence, support rules, backporting policy, and deprecation communication.
This document summarizes support end dates for recent RisingWave releases and provides a comprehensive overview of the software release lifecycle, including the versioning scheme, release cadence, and the detailed version support and deprecation policy. It helps users of RisingWave Cloud and the on-premises Premium edition understand how long different versions are supported and plan upgrades accordingly.
This policy focuses on software versions. For the lifecycle and deprecation of individual features, see RisingWave feature lifecycle and deprecation.
The following table summarizes support end dates for recent RisingWave releases. Refer to the detailed policy below for the rules governing these dates.
Future support-end dates will be updated as new versions are released.
Version | Release Date | Support Ends |
---|---|---|
v1.10 | Jul 30, 2024 | Jan 26, 2025 |
v2.0 | Sep 26, 2024 | Feb 11, 2025 |
v2.1 | Dec 7, 2024 | April 14, 2025 |
v2.2 | Feb 11, 2025 | May 22, 2025 |
v2.3 | April 14, 2025 | Upon the release of v2.5 |
v2.4 | May 22, 2025 | Upon the release of v2.6 |
RisingWave adheres to the Semantic Versioning (SemVer) standard, using a three-part numbering system: Major.Minor.Patch
. Understanding this scheme is crucial for interpreting the support policy.
2.0.0
): Represents significant, milestone releases. These releases often introduce substantial new features, architectural changes, and may include breaking changes. Breaking changes might require data migration or adjustments to user workflows.2.1.0
): Represents regular releases with new features, enhancements, and bug fixes.2.1.1
): Represents releases focused solely on bug fixes and security patches. Normally the latest patch version is the recommended version within a minor version.RisingWave aims for a predictable release schedule:
This section defines the rules for discontinuing support for older RisingWave versions. “Support” includes providing bug fixes, security patches, and technical assistance. When support ends, a version is considered deprecated.
3.1 Major version deprecation:
Support for a major version ends 4 months after the release of the subsequent major version.
Example: If RisingWave 3.0.0
is released on September 1st, 2025, then support for all 2.x.x
versions (e.g., 2.10.5
) that have not already been deprecated ends on January 1st, 2026. This provides a 4-month window for users to migrate.
3.2 Minor version deprecation:
3.3 Backporting policy:
Critical bug fixes and security patches are backported to a limited set of supported, non-deprecated versions. This ensures users receive essential updates even if not on the absolute latest version. Fixes are typically applied to:
Example: On March 5th, 2025, assume:
2.3.0
is undergoing release testing.2.2.0
is the latest released version.1.10.0
is from a previous major release but is still supported (within the 4-month window after 2.0.0
was released).In this scenario, critical fixes would be backported to 2.3.0
, 2.2.0
, and potentially 1.10.0
. Backporting to 2.1.0
would generally not occur if 2.3.0
had already been released (based on the minor version deprecation rule).
3.4 Exceptions:
RisingWave communicates version support changes and upcoming deprecations clearly and proactively.
5.1 Communication channels: Information is shared via:
5.2 Content of notifications: Deprecation notices typically include:
5.3 Advance notice:
5.4 Migration support: Where applicable, RisingWave provides tools, documentation (like migration guides), and support resources to assist with upgrades to supported versions.
5.5 Feedback mechanism: User feedback on the deprecation process and migration experience is encouraged through standard channels (e.g., forums, support tickets).