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

Question

我们正在改变我们的中间件（MW）软件的版本控制和依赖系统，我们在这里考虑这样的事情：

一个即可。的 B'/强> C 即可。的 d

a - 主要版本

b - 向后兼容性中断

c - 新功能

d - 错误修复

但稍微扭曲一下，因为我们必须将由于软件大小和网络速度慢而发送给客户端的软件包数量保持在最低限度。

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

为了更好地展示这一切，这里有几个例子：

增加逻辑

需要包装决策逻辑

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

Answer 1

只要您拥有整个公司理解并遵守的内部逻辑，就可以跳过版本号（或具有复杂的版本编号）。 （如果事情没有改变......微软将会跳过其Windows系统的第9版。）

[major]。[minor]。[release]。[build]被很多公司使用了很多。

在我们公司，我们在[build]之外添加了一个名为[private]的额外内容 [主要]。[次要]。[发布] [建立] [私人]

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

回到80年代，我还读到了关于版本编号心理学的一些内容。有些公司会直接跳到[次要]第3版，只是为了让它看起来比他们做的更多。他们也避免超过7，因为它使他们看起来像修复了太多错误，并且容易出现可怕的错误代码。这种对客户或客户的心理感受可能相当强烈，并且可能是程序员（他们倾向于正确的文字主义者）和营销人员（他们认为逻辑就像一些蓬松的思想之后）之间的巨大争论。

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

祝你好运。 ：）

Answer 2

  

[<强>主要]。[<强>次要]。[<强>释放]。[<强>构建]   （这篇文章广泛接受的模式：https://stackoverflow.com/a/615277/758378）

偏离模式

你有一个特定的理由这样做，所以我没有看到任何问题。 （你的具体逻辑对我来说也很好。）

关于不重置最后一个号码

这根本不是问题。在上面的链接答案中，您甚至可以看到使用SVN修订版作为建议使用的编号。