Redis 发布周期

Redis 的新版本如何发布？

Redis 是系统软件，也是一种保存用户数据的系统软件，因此它是软件堆栈中最关键的部分之一。

出于此原因，Redis 的发布周期确保了高度稳定的发布，即使是以牺牲较慢的周期为代价。

新版本发布在 Redis GitHub 存储库 中，也可以 下载。公告发送到 Redis 邮件列表，并由 @redisfeed 在 Twitter 上 发布。

发布周期

给定版本的 Redis 可以处于三个不同的稳定性级别

• 不稳定
• 候选版本
• 稳定

不稳定树

Redis 的不稳定版本位于 Redis GitHub 存储库 中的 unstable 分支中。

此分支是大多数新功能正在开发中的源代码树。unstable 不被认为已准备好投入生产：它可能包含严重错误、不完整的功能，并且可能不稳定。

但是，我们努力确保即使是不稳定分支在大多数情况下也可以在开发环境中使用，而不会出现重大问题。

候选版本

Redis 的新次要版本和主要版本最初是 unstable 分支的分支。分支的名称是目标版本

例如，当 Redis 6.0 作为候选版本发布时，unstable 分支被分叉到 6.0 分支。新分支是该版本的候选版本 (RC)。

在发布的时间范围内可以稳定的错误修复和新功能会提交到不稳定分支，并反向移植到候选版本分支。unstable 分支可能包括不属于候选版本且计划在未来版本中发布的其他工作。

一旦候选版本可用于开发目的和测试新版本，就会发布第一个候选版本，即 RC1。在这个阶段，新版本带来的大多数新功能和更改都已准备好进行审查，并且该版本的目的是收集公众的反馈。

后续候选版本大约每三周发布一次，主要用于修复错误。这些版本也可能会添加新功能并引入更改，但频率和最终候选版本面临的潜在风险会逐渐降低。

稳定树

一旦开发结束，并且候选版本的关键错误报告频率下降，它就已准备好进行最终发布。此时，该版本将标记为稳定版本，并以“0”作为其补丁级别版本发布。

版本控制

稳定版本自由遵循通常的major.minor.patch语义版本控制架构。主要目标是提供有关向后兼容性的明确保证。

补丁级别版本

补丁主要包括错误修复，极少会引入任何兼容性问题。

从以前的补丁级别版本升级几乎总是安全且无缝的。

可以添加新功能和配置指令，或更改默认值，只要这些功能和配置指令不会产生重大影响或引入与操作相关的问题即可。

次要版本

次要版本通常提供成熟度和扩展功能。

在次要版本之间升级不会引入任何应用程序级兼容性问题。

次要版本可能包括引入与操作相关的不兼容性的新命令和数据类型，包括数据持久性格式和复制协议中的更改。

主要版本

主要版本引入新功能和重大更改。

理想情况下，这些版本不会引入应用程序级兼容性问题。

发布计划

计划每年发布一个新主要版本。

通常，每个主要版本在六个月后都会推出一个次要版本。

根据需要发布补丁以修复高紧急问题，或者在稳定版本积累了足够的修复程序以证明有必要时发布补丁。

如需在敏感问题和安全问题上联系核心团队，请发送电子邮件至 redis@redis.io。

支持

通常情况下，不支持较旧版本，因为我们非常努力地使 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 得到维护。

以上是指导原则，而不是一成不变的规则，并且不会取代常识。