是否有意义不重置版本号中的最后一位数字

Question

我们正在改变我们的中间件(MW)软件的版本控制和依赖系统,我们在这里考虑这样的事情:

a.b.c.d

a - 主要版本

b - 向后兼容性中断

c - 新功能

d - 错误修复

但由于软件的大小和网络速度慢,我们必须将发送给客户端的软件包数量保持在最低限度.

因此,我们的想法是仅在向后兼容性更改时重置错误修复号.使用此逻辑,我们可以创建一个自动系统,如果客户端已经安装的版本有任何错误更改,并且它符合新的FrontEnd(FE)要求,则只生成新包.

为了更好地显示这一切,这里有几个例子:

递增逻辑

需要包决策逻辑

虽然这是一个非标准的版本控制逻辑,你们看到这个逻辑有什么问题吗？

Answer 1

只要您拥有整个公司都理解并遵守的内部逻辑，跳过版本号（或使用复杂的版本号）就没有问题。（如果情况不改变……微软将跳过 Windows 系统的第 9 版。）

[major].[minor].[release].[build] 被许多公司大量使用。

在我们公司，除了[构建]之外，我们还添加了一项额外的功能，称为[私有]。
[主要].[次要].[发布].[构建].[私有]

在我们的逻辑中，[private] 用于错误测试的内部排序。（我们故意破坏代码，以便测试错误。）但在发布代码之前，[private] 必须设置回零。因此，除非版本号末尾有 .0，否则任何代码都不会离开办公室。它提醒程序员删除（或注释掉）他们的测试代码，并提醒测试人员不要发送仅用于测试的代码。

早在 80 年代，我还读过一些有关版本编号心理学的内容。有些公司会直接跳到[次要]版本 3，只是为了让他们看起来好像做了比实际更多的测试。他们还避免超过 7，因为这让他们看起来像是修复了太多错误，并且很容易出现严重错误的代码。这种对客户或客户的心理感知可能相当强烈，并且可能会在程序员（他们往往是正确的字面主义者）和营销人员（他们将逻辑视为一些经过深思熟虑后的蓬松想法）之间展开一场巨大的争论。

考虑到这一点，回答你的问题：你的逻辑太棒了......现在把它卖给你的营销部门。（或者更好的是......不要把它卖给他们，只需实施它并希望他们不会来敲你的门，或隔间，或藏身之处。）

祝您的设计好运。:)