Support end dates for recent releases
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 | July 29, 2025 |
v2.4 | May 22, 2025 | Upon the release of v2.6 |
Policy details
1. Software versioning model (Semantic Versioning)
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.
- Major version (e.g.,
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. - Minor version (e.g.,
2.1.0
): Represents regular releases with new features, enhancements, and bug fixes. - Patch version (e.g.,
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.
2. Release cadence
RisingWave aims for a predictable release schedule:- Major versions: Typically released annually.
- Minor versions: Typically released every 45-75 days.
- Patch versions: Released as needed to address critical bugs and security vulnerabilities.
3. Version support and deprecation policy
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 all2.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:
- Support for a minor version X.Y ends upon the release of minor version X.Y+2. This means that at any given time, the two most recent minor versions are officially supported.
- Example: When version 2.3.0 is released, support for version 2.1.0 officially ends. At that point, the two supported minor versions are 2.3.0 (the latest) and 2.2.0. Users on 2.1.0 or older versions would need to upgrade to 2.2.0 or 2.3.0 to receive support.
To address performance issues observed with etcd, we strongly encourage all users of RisingWave v2.0 and earlier to upgrade to v2.1. Starting with v2.1, RisingWave supports SQL backends (PostgreSQL, MySQL, and SQLite) for metadata storage. Migrating to a SQL backend provides benefits such as improved stability, performance, and observability.
-
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:
- The latest released minor version.
- The minor version currently undergoing release testing.
- Potentially, one past major version, if it is still within its support window (see section 3.1). This is evaluated case-by-case.
-
Example: On March 5th, 2025, assume:
- Version
2.3.0
is undergoing release testing. - Version
2.2.0
is the latest released version. - Version
1.10.0
is from a previous major release but is still supported (within the 4-month window after2.0.0
was released).
2.3.0
,2.2.0
, and potentially1.10.0
. Backporting to2.1.0
would generally not occur if2.3.0
had already been released (based on the minor version deprecation rule). - Version
-
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:
-
3.4 Exceptions:
- In exceptional circumstances (e.g., critical security vulnerabilities, severe performance issues, legal requirements), a version may be deprecated, and support removed with shorter notice than outlined above. RisingWave will make every effort to inform users promptly in such cases.
4. RisingWave Cloud specifics
- RisingWave Cloud users receive notifications about version deprecation directly through the cloud portal and potentially via email.
- The upgrade process for deprecated versions may be automated using published maintenance windows. Details on automation will be provided when available.
- Until automation is fully implemented, the RisingWave Cloud SRE team coordinates with customers regarding necessary upgrades to stay within supported versions.
5. Communication and user support
RisingWave communicates version support changes and upcoming deprecations clearly and proactively.-
5.1 Communication channels: Information is shared via:
- Product release newsletter
- Blog posts
- Release notes
- Direct emails (to potentially affected users)
- In-product notifications (within RisingWave Cloud)
-
5.2 Content of notifications: Deprecation notices typically include:
- The specific version(s) being deprecated (e.g., “RisingWave 1.5.x”).
- A clear timeline: announcement date, end-of-support date (deprecation date).
- Guidance on migration paths and resources.
-
5.3 Advance notice:
- RisingWave provides at least 2 months’ notice before support ends for a major version. The exact timeline considers the impact of the new major release. Notice for minor version deprecation is implicit in the release cadence and the policy rules (section 3.2).
- 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).