Redis的发布周期
Redis是一种系统软件，也是一种保存用户数据的系统软件，因此它是软件栈中最关键的部分之一。
基于此原因，Redis的发布必须确保其高稳定性，即使以较长的周期为代价。
关于新版本的发布，请及时关注虹科云科技官方网站。
发布周期
给定版本的Redis具有三种不同的稳定性：
- 不稳定的
- 候选版本
- 稳定的
不稳定版
Redis的不稳定版本位于Redis GitHub存储库的unstable分支中。
此分支是大多数新特征正在开发的源代码树。unstable不被认为是开发就绪的：它可能包含严重的错误、不完整的功能，并且可能不稳定。
但是，我们努力确保即使是不稳定的版本，在开发环境中的大多数时间都是可用的，没有重大问题。
候选版本
新的Redis次要和主要版本从unstable的分支开始。分支的名称分别是目标版本。
例如，当Redis 6.0作为候选版本发布时，该unstable分支被分叉到该6.0分支中。新分支是该版本的候选发布(RC)。
在发布的时间范围内可以稳定的进行错误修复和新功能开发的版本都被提交到不稳定分支，并回传到候选发布分支。unstable分支可能包括不属于候选版本的额外工作，这些工作计划在未来的版本中进行。
第一个候选发布版本，即RC1，一旦可以用于开发目的和测试新版本，就会被发布。在这个阶段，新版本所带来的大部分新功能和变化已经准备好接受审查，而发布的目的是收集公众的反馈。
后续的候选版本大约每三周发布一次，主要用于修复bug。这些还可能添加新特性和引入更改，但速度会降低，并降低最终候选版本的潜在风险。
稳定版本
一旦开发工作结束，候选发布版本的关键错误报告频率降低，它就可以进入最终发布阶段。这时，该版本被标记为稳定版，并以 “0 “作为其补丁级版本发布。
版本管理
稳定的发行版遵循通常的主要版本。少数的修补语义版本控制架构。主要目标是提供有关向后兼容性的明确保证。
补丁级版本
补丁主要由错误修复组成，很少引入任何兼容性问题。
从以前的补丁级版本升级，几乎总是安全和无缝的。
可以添加新的功能和配置指令，或改变默认值，只要这些不会带来重大影响或引入与操作有关的问题。
次要版本
次要版本通常提供成熟的和可扩展的功能。
在次要版本之间的升级不会引入任何应用层面的兼容性问题。
次要版本可能包括新的命令和数据类型，引入与操作有关的不兼容问题，包括数据持久化格式和复制协议的变化。
主要版本
主要版本引入了新功能和重大变化。
理想情况下，这些不会引入应用程序级别的兼容性问题。
发布时间表
计划每年发布一次新的主要版本。通常，每个主要版本都会在六个月后发布一个次要版本。补丁会根据需要发布，以解决紧急问题，或者一旦稳定版本积累了足够的补丁来证明其合理性。
通常，旧版本不受支持，因为我们努力使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版本。