注：本博客由「柏油」翻译自 redis.io/docs/about/… , 转载请注明出处！
译文如下：
Redis release cycle
Redis 发版周期
Redis 新版本如何发布的？
Redis 是系统软件，并且是处理用户数据的软件，也就是说，它处于软件栈关键的一环上。
基于此，Redis 版本周期以较慢的迭代速度为代价，来保证新版本较高的稳定性。
Redis 各发布版本都放在 Redis Github 仓库, 可以通过链接 下载 ，相关公告会通过邮件或者 twitter 账号通知。
发布周期
一个正式的 Redis 版本会存在 3 种不同的稳定性版本：
- Unstable：不稳定版本
- Release Candidate：候选版本
- Stable：稳定版本
不稳定版
在 Redis Github 仓库 中专门使用了名为 unstable 的分支来表示「不稳定版」
该分支包含当下「最新特性」开发，不会考虑立即投入生产使用：
- 可能包含致命 BUG
- 特性功能不够完整
- 其他潜在风险等
不过，我们也尽量保证「不稳定版」在开发环境的大部分情况下都是稳定可用的，至少不会出现重大缺陷。
候选版本
大版本 或 小版本 发版都需要先从「不稳定版」Fork 分支，并且将分支名定义为目标版本号。
例如，当选择 Redis 6.0 作为一个「候选版本」发布时，先从「不稳定版」分支 Fork 一个新分支，分支名为 6.0。
注：从
unstable分支 fork 出来的目标发行版距离真正可发行时间点，需要经历漫长的验证周期，一般情况下，会经历多个 RC 版本，比如，redis6.2 的稳定版经历了 6.2-rc1、6.2-rc2、6.2-rc3 等三个候选版本，最终发布 redis 6.2.0 稳定版本。
在当前版本发布时间范围内，对于一些提交到 unstable 分支并且已经稳定的「BUG修复」和「新特性」也会合并到当前版本的 RC 分支内。
值得注意的是，unstable 分支可能包含了额外的功能，并计划在未来某个版本发布，也就是说，这些功能就不会合并到当前进行中的 RC 版本了。
当第一个候选版本（RC1）发布时，就可以直接部署进入测试阶段了，在这个阶段，新版本带来的「特性」和「修改」都会进一步得到验证，RC 版本主要的目的是收集公众反馈，即「公测」。
后续候选版本大概 3周 发布一次，主要是「BUG修复」，当然也会包含少量「特性」或者「修改」，随着 RC 版本的迭代，这些更新会持续减少，直到 Final RC 版（即稳定版）
稳定版
经过多轮 RC 迭代验证 + 修复，最终进入 Final Release 版，此时，该 Release 会被标记为stable，同时，使用 "0" 表示补丁版本号，比如 6.2.0（6 代表大版本号，2 代表小版本号，0 代表补丁版本号）。
版本：
版本号：stable 稳定版采用 major.minor.patch 三段版本号，主要目的是为了明确保证后向兼容性。
补丁版本
即 patch。主要是「BUG修复」或者少量的「兼容性」问题。
当然，只要不产生重大影响或引入与操作相关的问题，就可以添加新特性和配置指令，或更改默认值。
值得注意的是，从上一个补丁升级到当前补丁是非常安全且平滑的。
小（次）版本
即 Minor。通常是提供成熟和扩展的功能。
小版本之间的升级不会引入任何应用程序级别的兼容性问题。
小版本可能引入与操作相关的不兼容性的新命令和数据类型，包括数据持久性格式和复制协议的更改。
大（主）版本
即 Major。主要版本引入了新功能和重大更改。
理想情况下，这些不会引入应用程序级别的兼容性问题。
发布时间表
一个新的大版本计划每年发布一次。
通常情况下，每个大版本发布后，6个月后都会有一个小版本。
补丁会在需要时发布，以修复高度紧急的问题，或者在稳定版本积累了足够的补丁后发布。
支持
一般来说，无法完全兼容旧版本，我们只能尽量做到大部分 Redis API 向后兼容性。
通常我们是推荐升级到最新版本，操作也十分简单，最新的稳定版本通常会得到充分的支持和维护。
一般情况下，只有两个稳定版本会继续维护，主要维护「BUG修复」或者「安全相关的issue」并作为补丁发布。
- 当前稳定版的前一个小版本，继续维护
- 当前稳定版本的前一个大版本，继续维护。
例如，考虑以下版本：1.2, 2.0, 2.2, 3.0, 3.2
- 当 2.2 是目前最新稳定版时，版本 1.2 和 2.0 继续维护
- 一旦 3.0 成为最新稳定版时，版本 2.0 和 2.2 继续维护，而 1.x 则停止维护
- 当 3.2 成为目前最新稳定版时，版本 2.2 和 3.0 继续维护
以上是指导方针，不是一成不变的规则，不能取代常识。
