*Redis发布周期

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

因此，Redis的发布周期会尽力确保只有在达到足够高的稳定性时才发布稳定的发布，即使是以较慢的发布周期为代价。

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

*不稳定的树

Redis的不稳定版本始终位于Redis GitHub Repository中的unstable分支中。

这是大多数新功能都在开发中的源代码树，不被认为已准备好投入生产：它可能包含严重的bug，但尚未完全就绪，并且可能不稳定。

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

当开始计划新版本的Redis时，不稳定的分支（或有时是当前稳定的分支）将分支到具有目标发行版名称的新分支中。

例如，当Redis 2.6作为稳定版发布时，unstable分支分支到2.8分支中。

这个新分支可以处于三个不同的稳定性级别：开发，冻结和发布候选。

开发：新功能和错误修复已提交到分支中，但并不是所有unstable合并到此的内容。仅合并可以在合理时间内稳定的功能。
冻结：未添加任何新功能，除非几乎可以保证对源代码的零稳定性影响，并且出于某种原因，这是必须尽快交付的非常重要的功能。大型代码更改仅在需要它们才能修复错误时才允许。
候选版本：仅针对此版本提交修复程序。

在某个时候，当给定的Redis版本处于"候选发布"状态足够长的时间时，我们观察到发出严重bug的频率开始下降，以至于在几周内我们没有任何严重的bug。报告。

发生这种情况时，版本将标记为稳定。

稳定版本遵循通常的major.minor.patch版本控制架构，并具有以下特殊规则：

次要版本甚至在Redis的稳定版本中也是如此。
未成年人在不稳定，发展，冻结，释放的候选人方面很奇怪。例如，不稳定的2.8.x版本将具有2.7.x形式的版本号。通常，不稳定版本的xyz将具有版本x.(y-1).z。
随着Redis不稳定版本的进行，补丁程序级别会不时增加，因此在给定的时间，您可能会有2.7.2，然后是2.7.3，依此类推。但是，当达到发布候选状态时，补丁程序级别将从101开始。因此，例如2.7.101是2.8的第一个发布候选，2.7.105是发布候选5，依此类推。

不支持旧版本，因为我们非常努力地使Redis API大部分向后兼容。升级到较新版本通常很简单。

例如，如果当前的稳定版本是2.6.x，则我们接受错误报告并提供对先前稳定版本（2.4.x）的支持，但不支持较早的版本（例如2.2.x）。

当2.8成为当前的稳定版本时，2.6.x将是受支持的最早版本。