Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions content/develop/clients/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,9 @@ However, we contribute new features, offer guidance, and collaborate with the co
on a best-effort basis to help ensure these libraries remain reliable and up-to-date.
{{< /note >}}

See [Client library support and versioning policy]({{< relref "/develop/clients/version-support" >}})
for details about how Redis maintains, versions, and tests the official client libraries.

We also provide several higher-level
[object mapping (OM)]({{< relref "/develop/clients/om-clients" >}})
libraries for [Python]({{< relref "/integrate/redisom-for-python" >}}),
Expand Down
94 changes: 94 additions & 0 deletions content/develop/clients/version-support.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
---
aliases: /develop/connect/clients/version-support
categories:
- docs
- develop
- stack
- oss
- rs
- rc
- oss
- kubernetes
- clients
description: Understand how Redis maintains and versions its official client libraries
linkTitle: Support & versioning
title: Client library support and versioning policy
weight: 150
---

Official Redis client libraries are covered by the
[Redis Software Support Policy](https://redis.io/legal/software-support-policy/).
This page describes the client-library-specific maintenance and versioning
policy that clarifies active support, testing expectations, and backporting
rules for those clients.

The policy is based on the non-EOL Redis Server **major.minor** versions
currently available in Redis Cloud, as listed in
[Supported database versions]({{< relref "/operate/rc/databases/version-management#supported-database-versions" >}}).

## Versioning

Redis client libraries use a `major.minor.patch` versioning scheme that follows
[Semantic Versioning 2.0.0](https://semver.org/):

- **Major** versions may introduce incompatible API changes.
- **Minor** versions add backward-compatible functionality.
- **Patch** versions contain backward-compatible bug fixes.

## Maintained release line

The latest `major.minor` release of each official Redis client library is the
primary maintained release line. In practice, this means it is the line under
active development and the one where regular bug fixes and new features are
delivered.

Client libraries follow a forward-moving model: each new `major.minor` release
is cut from the main branch, and a version branch is created at the same time
for future patch and maintenance releases (for example, `5.2.x`).

## Supported Redis API versions

Each new client `major`, `minor`, and `patch` release is tested against a
compatibility matrix of the
[non-EOL Redis API versions]({{< relref "/operate/rc/databases/version-management#supported-database-versions" >}})
currently available. For example, if the supported API versions are 6.2, 7.2,
and 7.4, then each client release is tested against all three. The release notes
for each client report the compatibility matrix used for testing.

The table below shows some examples of client releases and the API versions they
are tested against:

| Example client release | Supported Redis API versions | Client testing targets |
| :-- | :-- | :-- |
| Jedis 5.2 | 6.2, 7.2, 7.4 | Test with 6.2, 7.2, 7.4 |
| redis-py 5.3 | 6.2, 7.2, 7.4, 8.0 | Test with 6.2, 7.2, 7.4, 8.0 |
| Jedis 6.0 | 6.2, 7.2, 7.4, 8.2 | Test with 6.2, 7.2, 7.4, 8.2 |

A similar matrix is also published on each client library's GitHub repository.

## Bugs, vulnerabilities, and community contributions

Redis keeps innovation on the latest maintained line and reserves older lines
for critical fixes and security updates. This keeps the support matrix clean and
reduces the testing and maintenance overhead of supporting many branches at once.

- **Regular bug fixes** are delivered either in a new `major.minor` release or,
depending on the overall content, in a new patch release on the current
maintained line. Non-critical bug fixes and new features are *not* backported
to older client `major.minor` versions. For example, if a bug is found in a
client library release 5.2 and the fix is released in 5.2.1, the same
non-critical fix is not backported to older versions such as 5.1.
- **Critical bugs and security vulnerabilities**, including CVEs, are backported
to the latest patch version of a `major.minor` and may also be backported to
patch releases of older versions.
- **Community-contributed fixes** to older versions are reviewed on a
case-by-case basis. If a fix is considered useful for future versions, it is
also ported to the main branch for a future major, minor, or patch release.

## Recommendations

- Use the latest `major.minor` client library release available.
- Read the release notes for version-specific changes and for the compatibility
matrix used in testing.
- Test upgrades with production-like workloads and configurations before rolling
them out broadly, especially when moving across major or minor versions.
Loading