“链式”版本升级的名称？

Question

考虑实现具有多个版本的东西的升级的两种策略(例如升级一些软件的安装)。

1. 从任何版本中，直接升级到最新版本。
2. 通过中间版本逐步升级，直到您获得最新版本。

选项2是否有公认的名称？

示例

例如，您使用的是7.0版本，您希望获得最新版本9.1。升级在内部工作，使用以下链接步骤。

any -> 8.0
8.0 -> 9.0
9.0 -> current (9.1)

Answer 1

In

策略1是直接升级。

策略2是一个顺序升级(例如RedHat)或连续发布升级(例如MongoDB或MySql，至少在以前的版本中是这样)。但要小心，因为没有权威的定义或普遍接受的术语。

术语可能会误导

与升级相关的术语是棘手的，而且常常是误导人的。

以Robert的增量升级为例：

• 对于任何敏捷开发人员，解决方案都是以增量方式交付的。因此，可以很容易地将后续版本看作是自然的增量。
• 然而，在Robert提到的Google 专利中，更确切地说，在关于现有技术的一节中，增量用于指补丁:它反对将一个版本的可执行文件完全替换为另一个版本的可执行文件。
• 因此，增量升级可能指的是非常不同的东西，对于不同的人有不同的意义。而且它没有解决您的问题，因为增量的粒度没有定义:它是一个补丁还是一个版本？

以upgrade博士的累积升级为例：

• 策略1显然不是累积的。
• 如果将补丁添加到所需的版本，策略2可以是累积的。但是，您也可以在下一个版本之前替换每个版本，因此这是一个连续的替换，没有任何累积。
• 累积的问题是它有一个技术内涵的积累小的东西。同样，对于不同的人来说，这也可能意味着不同的事情。

将自己限制在共同同意的条件下，

以下术语得到广泛接受和使用：

• 升级路径描述了从源版本升级到目标版本的方法。
• 直接升级是指您可以直接从源升级到目标，而无需使用中间版本。
• 中间版本是路径上的版本。

任何其他更精确的术语都要谨慎对待。即使在您自己的示例中，也不清楚是否可以跳过次要版本(在8.0到9.0之间)，以及后续版本是否只适用于相同的版本控制级别。

这就是为什么最大的供应商广泛地使用升级路径，用完整的句子来描述这个路径在一般情况下的样子，并在nice矩阵中显示可能的路径(这也允许在旧版本中处理由于策略改变而导致的许多异常)。

Answer 2

选项1通常被称为“累积升级”，这使得选项2只是“非累积的”。是的，罗伯特·哈维也是对的，#2也被称为“增量升级”。注意，“增量”或“累积”一词不限于软件升级，它们适用于对文档或数据的任何类型的更改。