RisingWave release lifecycle and version support policy

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.

​

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.

​

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 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:

  • 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.

• 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 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:

  • 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).