{
  "id": "version-support",
  "title": "Client library support and versioning policy",
  "url": "https://redis.io/docs/latest/develop/clients/version-support/",
  "summary": "Understand how Redis maintains and versions its official client libraries",
  "tags": [
    "docs",
    "develop",
    "stack",
    "oss",
    "rs",
    "rc",
    "oss",
    "kubernetes",
    "clients"
  ],
  "last_updated": "2026-06-24T14:16:43-05:00",
  "page_type": "content",
  "content_hash": "7706d61175d3f041408810e91858aa2a0be7d7d5a35b3934b528fee88ad5a01d",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "Official Redis client libraries are covered by the\n[Redis Software Support Policy](https://redis.io/legal/software-support-policy/).\nThis page describes the client-library-specific maintenance and versioning\npolicy that clarifies active support, testing expectations, and backporting\nrules for those clients.\n\nThe policy is based on the non-EOL Redis Server **major.minor** versions\ncurrently available in Redis Cloud, as listed in\n[Supported database versions](https://redis.io/docs/latest/operate/rc/databases/version-management#supported-database-versions)."
    },
    {
      "id": "versioning",
      "title": "Versioning",
      "role": "compatibility",
      "text": "Redis client libraries use a `major.minor.patch` versioning scheme that follows\n[Semantic Versioning 2.0.0](https://semver.org/):\n\n-   **Major** versions may introduce incompatible API changes.\n-   **Minor** versions add backward-compatible functionality.\n-   **Patch** versions contain backward-compatible bug fixes."
    },
    {
      "id": "maintained-release-line",
      "title": "Maintained release line",
      "role": "content",
      "text": "The latest `major.minor` release of each official Redis client library is the\nprimary maintained release line. In practice, this means it is the line under\nactive development and the one where regular bug fixes and new features are\ndelivered.\n\nClient libraries follow a forward-moving model: each new `major.minor` release\nis cut from the main branch, and a version branch is created at the same time\nfor future patch and maintenance releases (for example, `5.2.x`)."
    },
    {
      "id": "supported-redis-api-versions",
      "title": "Supported Redis API versions",
      "role": "compatibility",
      "text": "Each new client `major`, `minor`, and `patch` release is tested against a\ncompatibility matrix of the\n[non-EOL Redis API versions](https://redis.io/docs/latest/operate/rc/databases/version-management#supported-database-versions)\ncurrently available. For example, if the supported API versions are 6.2, 7.2,\nand 7.4, then each client release is tested against all three. The release notes\nfor each client report the compatibility matrix used for testing.\n\nThe table below shows some examples of client releases and the API versions they\nare tested against:\n\n| Example client release | Supported Redis API versions | Client testing targets |\n| :-- | :-- | :-- |\n| Jedis 5.2 | 6.2, 7.2, 7.4 | Test with 6.2, 7.2, 7.4 |\n| redis-py 5.3 | 6.2, 7.2, 7.4, 8.0 | Test with 6.2, 7.2, 7.4, 8.0 |\n| Jedis 6.0 | 6.2, 7.2, 7.4, 8.2 | Test with 6.2, 7.2, 7.4, 8.2 |\n\nA similar matrix is also published on each client library's GitHub repository."
    },
    {
      "id": "bugs-vulnerabilities-and-community-contributions",
      "title": "Bugs, vulnerabilities, and community contributions",
      "role": "content",
      "text": "Redis keeps innovation on the latest maintained line and reserves older lines\nfor critical fixes and security updates. This keeps the support matrix clean and\nreduces the testing and maintenance overhead of supporting many branches at once.\n\n-   **Regular bug fixes** are delivered either in a new `major.minor` release or,\n    depending on the overall content, in a new patch release on the current\n    maintained line. Non-critical bug fixes and new features are *not* backported\n    to older client `major.minor` versions. For example, if a bug is found in a\n    client library release 5.2 and the fix is released in 5.2.1, the same\n    non-critical fix is not backported to older versions such as 5.1.\n-   **Critical bugs and security vulnerabilities**, including CVEs, are backported\n    to the latest patch version of a `major.minor` and may also be backported to\n    patch releases of older versions.\n-   **Community-contributed fixes** to older versions are reviewed on a\n    case-by-case basis. If a fix is considered useful for future versions, it is\n    also ported to the main branch for a future major, minor, or patch release."
    },
    {
      "id": "recommendations",
      "title": "Recommendations",
      "role": "content",
      "text": "-   Use the latest `major.minor` client library release available.\n-   Read the release notes for version-specific changes and for the compatibility\n    matrix used in testing.\n-   Test upgrades with production-like workloads and configurations before rolling\n    them out broadly, especially when moving across major or minor versions."
    }
  ],
  "examples": []
}