Redis 发布周期

Redis 的新版本是如何发布的？

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

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

新版本发布在Redis GitHub 存储库 (opens new window) 中，也可供下载 (opens new window)。公告将发送到 Redis 邮件列表 (opens new window)，并由 Twitter 上的 @redisfeed (opens new window)发送。

发布周期

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

• 不稳定
• 发布候选
• 稳定的

不稳定的树

Redis 的不稳定版本位于Redis GitHub 存储库 (opens new window)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 版本。

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