客户端库支持与版本策略

提示

来自deepseek解释

原文链接：https://redis.io/docs/latest/develop/clients/version-support/

官方 Redis 客户端库受 Redis 软件支持政策 的约束。本页面描述了客户端库特定的维护和版本策略，阐明了这些客户端的主动支持、测试预期和向后移植规则。

该策略基于 Redis Cloud 中当前可用的非 EOL（停止支持）Redis Server 主版本.次版本，如支持的数据库版本中所列。

版本管理

Redis 客户端库采用 major.minor.patch 版本方案，遵循语义化版本 2.0.0：

• 主版本 可能引入不兼容的 API 变更。
• 次版本 添加向后兼容的功能。
• 补丁版本 包含向后兼容的缺陷修复。

维护的发布线

每个官方 Redis 客户端库的最新 major.minor 版本是主要的维护发布线。实际上，这意味着它是正在积极开发的版本线，也是定期发布缺陷修复和新功能的版本线。

客户端库遵循向前推进模型：每个新的 major.minor 版本从主分支切出，同时创建一个版本分支用于未来的补丁和维护发布（例如 5.2.x）。

支持的 Redis API 版本

每个新的客户端 major、minor 和 patch 版本都针对当前可用的非 EOL Redis API 版本的兼容性矩阵进行测试。例如，如果支持的 API 版本为 6.2、7.2 和 7.4，则每个客户端版本都会针对这三个版本进行测试。每个客户端的发布说明会报告用于测试的兼容性矩阵。

下表展示了一些客户端发布版本及其测试所针对的 API 版本的示例：

示例客户端发布版本	支持的 Redis API 版本	客户端测试目标
Jedis 5.2	6.2, 7.2, 7.4	使用 6.2, 7.2, 7.4 测试
redis-py 5.3	6.2, 7.2, 7.4, 8.0	使用 6.2, 7.2, 7.4, 8.0 测试
Jedis 6.0	6.2, 7.2, 7.4, 8.2	使用 6.2, 7.2, 7.4, 8.2 测试

类似的矩阵也会在每个客户端库的 GitHub 仓库中公布。

缺陷、漏洞与社区贡献

Redis 将创新保留在最新的维护线上，并为旧版本保留关键修复和安全更新。这保持了支持矩阵的清晰，并减少了同时支持多个分支的测试和维护开销。

• 常规缺陷修复 会以新的 major.minor 版本发布，或者根据整体内容，以当前维护线上的新补丁版本发布。非关键缺陷修复和新功能不会被向后移植到较旧的客户端 major.minor 版本。例如，如果在客户端库 5.2 版本中发现一个缺陷，并且修复在 5.2.1 中发布，则该非关键修复不会向后移植到 5.1 等较旧版本。
• 关键缺陷和安全漏洞（包括 CVE）会被向后移植到 major.minor 的最新补丁版本，也可能被向后移植到较旧版本的补丁版本中。
• 社区贡献的针对较旧版本的修复 会逐案审查。如果修复被认为对未来版本有用，也会移植到主分支，用于未来的主版本、次版本或补丁版本。

建议

• 使用可用的最新 major.minor 客户端库版本。
• 阅读发布说明，了解特定版本的变更以及测试中使用的兼容性矩阵。
• 在广泛部署之前，使用类似生产环境的工作负载和配置测试升级，尤其是在跨越主版本或次版本时。