Redis 8 已发布——并且它是开源的
了解更多
Redis 的新版本是如何发布的？
Redis 是系统软件，也是一种存放用户数据的系统软件，因此它是软件堆栈中最关键的部分之一。
因此，Redis 的发布周期设计旨在确保高度稳定的版本，即使这可能意味着更慢的周期。
新版本发布在 Redis GitHub 仓库中，并可供下载。发布公告会发送到 Redis 邮件列表和 Twitter 上的 @redisfeed。
Redis 的一个给定版本可以有三种不同的稳定级别
Redis 的不稳定版本位于 Redis GitHub 仓库中的 unstable 分支。
此分支是大多数新功能正在开发中的源代码树。unstable 版本不被视为生产就绪：它可能包含严重错误、不完整的功能，并且可能不稳定。
然而，我们努力确保即使不稳定分支在开发环境中大多数时间也是可用的，没有重大问题。
Redis 的新的次要版本和主要版本始于对 unstable 分支的分叉。分叉分支的名称就是目标发布版本
例如，当 Redis 6.0 作为发布候选版本发布时，unstable 分支被分叉到 6.0 分支。新分支就是该版本的发布候选版本 (RC)。
在发布时间范围内可以稳定的错误修复和新功能会提交到 unstable 分支，并向后移植到发布候选分支。unstable 分支可能包含不属于发布候选版本并计划用于未来版本的额外工作。
第一个发布候选版本，即 RC1，在其可用于开发目的和测试新版本时发布。在此阶段，新版本带来的大多数新功能和变更已准备好供审查，发布的目的是收集公众的反馈。
随后的发布候选版本大约每三周发布一次，主要用于修复错误。这些版本也可能添加新功能和引入变更，但随着接近最终发布候选版本，其添加速度和潜在风险会降低。
一旦开发完成且发布候选版本的严重错误报告频率降低，就可以进行最终发布。此时，该版本被标记为稳定版，并以“0”作为其补丁级别版本发布。
稳定版本基本上遵循通常的 major.minor.patch 语义版本控制模式。主要目标是提供关于向后兼容性的明确保证。
补丁主要包含错误修复，极少引入任何兼容性问题。
从先前的补丁级别版本升级几乎总是安全无缝的。
可以添加新功能和配置指令，或更改默认值，只要这些不会带来重大影响或引入操作相关问题。
次要版本通常带来成熟度和扩展功能。
在次要版本之间升级不会引入任何应用程序级别的兼容性问题。
次要版本可能包含引入操作相关不兼容性的新命令和数据类型，包括数据持久化格式和复制协议的变更。
主要版本引入新能力和重大变更。
理想情况下，这些不会引入应用程序级别的兼容性问题。
计划每年发布一个新的主要版本。
通常，每个主要版本发布后六个月会跟着一个次要版本。
补丁根据需要发布，以修复高紧急性问题，或者当一个稳定版本累积了足够的修复值得发布时。
如需就敏感事项和安全问题联系核心团队，请发送电子邮件至 [email protected]。
通常，旧版本不受支持，因为我们非常努力地使 Redis API 大部分保持向后兼容。
升级到新版本是推荐的方法，并且通常很简单。
最新的稳定版本始终得到全面支持和维护。
另外两个版本仅获得维护，这意味着只有针对关键错误和主要安全问题的修复会被提交并作为补丁发布
例如，考虑以下假设版本：1.2、2.0、2.2、3.0、3.2。
当版本 2.2 是最新的稳定版本时，2.0 和 1.2 都得到维护。
一旦版本 3.0.0 取代 2.2 成为最新的稳定版本，版本 2.0 和 2.2 将得到维护，而版本 1.x 则到达其生命周期终点。
这个过程在版本 3.2.0 发布后重复，此后只有版本 2.2 和 3.0 得到维护。
上述内容是指导方针，而非一成不变的规则，不能取代常识。
