YugabyteDB and YugabyteDB Anywhere have three kinds of releases:

• Stable, with Long-term support (LTS)
• Stable, with Standard-term support (STS)
• Preview, with no official support

Additionally, individual features may also be designated as tech preview or early access, or generally available. These designations indicate the feature maturity level, and provide different levels of documentation and support as described in Feature maturity.

Release versioning convention for Stable releases

YugabyteDB follows the below-described convention for numbering release versions.

Release versions follow the versioning format of YYYY.N.MAINTENANCE.PATCH as follows:

• YYYY.N - Includes substantial changes, such as new features and possibly incompatible API changes. YYYY is the year (for example, 2024). N is either 1 or 2 designating either the first release of the year, or the second. Such major releases occur roughly every 6 months. Generally, one of these releases (and its derivative maintenance and patch releases) per year is designated as LTS, and the other is designated as STS.

• MAINTENANCE - Includes releases which occur roughly every 1-2 months.

  • For YugabyteDB, backward compatible bug fixes are included.
  • For YugabyteDB Anywhere, functionality may be added in a backward compatible manner.

• PATCH - Includes bug fixes and revisions that do not break backward compatibility.

On rare occasions, YugabyteDB may issue a hot fix release. Hot fix releases are for specific point issues, and usually offered only to specific customers. Hot fix releases append an additional number to the release versioning convention as YYYY.N.MAINTENANCE.PATCH.HOTFIX.

Features in stable releases are considered to be GA unless marked otherwise.

Release versioning convention for Preview releases

Preview releases, which include features under active development, are recommended for development and testing only.

Preview release versions use the versioning format of MAJOR.MINOR.PATCH.HOTFIX, where non-negative integers are used as follows:

• MAJOR — Includes substantial changes.
• MINOR — Incremented when new features and changes are introduced. Currently, by convention for historical reasons, the MINOR integer is always odd; thus, successive MINOR releases increment this number by 2 (for example, 23, 25, 27, and so on.)
• PATCH - Patches in the preview release series (MAJOR.ODD.PATCH) focus on bug fixes that do not break backward compatibility. At the same time however, new features and changes may be are introduced that might break backward compatibility.
• HOTFIX - On rare occasions, a hot fix is required to address an issue without delay.

Releases in the preview release series, denoted by MAJOR.ODD versioning, are under active development and incrementally (with each MINOR release) introduce new features and changes.

Preview releases are the basis from which stable releases are derived. That is, the code base from a preview release is branched, and then hardened to become a stable release. The v2.21 preview release series, for example became the basis for the v2024.1 STS release series.

Note that while most features in a preview release series do appear in the derivative stable release, this cannot be guaranteed; some features may remain internally disabled in the derivative stable release series to allow more time for the feature to be completed.

Features in preview releases are considered to be TP unless marked otherwise.

Patch releases in the preview release series (MAJOR.ODD.PATCH) introduce new features, enhancements, and fixes.

Feature maturity

YugabyteDB features are made available as one of the following:

• TP Tech Preview
• EA Early Access
• GA General Availability

Changes for EA and GA are always reported in the Release Notes.

Tech Preview (TP)

Features in Tech Preview (TP) are managed and supported by the Product Team and have been internally validated for a set of use cases. Minimal documentation is directly provided to customers and is normally not publicly hosted.

TP features aren't supported by Customer Support and may change at any time during the preview.

If you are interested in a TP feature, contact Yugabyte Support.

Participating customers agree to provide feedback to the Product Team. However, the timeline for addressing specific areas of feedback (including bugs) is at the discretion of Yugabyte.

Documentation (if provided) for TP features is marked as such.

Early Access (EA)

A feature in Early Access (EA) is new or enhanced functionality made available for you to use.

Code is well tested. Typically these features are not enabled by default. Enabling the feature is considered safe.

Support for the overall feature will not be dropped, though details may change in a subsequent GA release.

For production use cases, it is recommended to validate the use case with the Yugabyte Product team. Refer to product documentation for specific limitations.

Any bug fixes or improvements are managed and fixed with the same timeline and processes as those in GA.

EA features in YugabyteDB Aeon are not subject to the YugabyteDB Aeon SLA.

Give feedback on EA features on our Slack community or by filing a GitHub issue.

Documentation for EA features is marked as such.

General Availability (GA)

A feature in General Availability (GA) is enabled and accessible by default for all customers.

GA features are supported by Yugabyte Support, and issues are addressed according to the stable release support policy.

Any feature not marked Tech Preview or Early Access should be considered GA.

Deprecation

A feature identified as deprecated is no longer recommended for use and may be removed in the future. This means that you shouldn't use it unless you have to. Any workarounds or recommended paths forward are included in the relevant documentation, libraries, or references.

Documentation for features that have been deprecated are indicated as such.

Minor and cosmetic changes

Minor and cosmetic changes are not marked TP or EA, including the following:

• Bug fixes that change only the incorrect behavior of the bug.
• Cosmetic changes, such as changing the label of a field in the administrator UI.
• Changes that are narrow in scope or effect, or purely additive, such as adding a new attribute.

All changes that affect customers are reported in the Release Notes.