Redis【有与无】【Admin-14】Redis发布周期

最新推荐文章于 2024-05-12 17:43:45 发布

琴韵

最新推荐文章于 2024-05-12 17:43:45 发布

阅读量274

点赞数

分类专栏： Redis 文章标签： redis

本文链接：https://blog.csdn.net/u012549626/article/details/110777395

版权

52 篇文章 6 订阅

订阅专栏

本文基于Redis 6.0.9版本，前提至少 Redis 3.0或更高版本。

1.Redis发布周期

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

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

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

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

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

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

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

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

这个新分支可以处于三个不同的稳定性级别：development, frozen, release。

Development: 新功能和错误修复已提交至分支，但并非所有进入不稳定状态的内容都在此处合并。仅合并可以在合理时间内稳定的功能。
Frozen: 除非几乎可以保证对源代码的零稳定性影响，否则不添加任何新功能ASAP，并且由于某种原因，这是必须尽快交付的非常重要的功能。仅当需要大代码更改才能修复错误时，才允许进行大代码更改。
Release Candidate: 仅针对此版本提交修复程序。

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

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

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

次要版本甚至在Redis的稳定版本中也是如此。
minor在unstable, development, frozen, release候选者方面很奇怪。例如，不稳定版本的2.8.x将具有2.7.x形式的版本号。通常，不稳定版本的x.y.z将具有版本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将成为受支持的最早版本。

关注