我们正在更改我们的中间件 (MW) 软件的版本控制和依赖系统，我们正在考虑这样的事情：
a.b.c.d
a - 主要版本
b - 向后兼容中断
c - 新功能
d - 错误修复
但有点扭曲，因为由于软件的大小和缓慢的网络，我们必须将发送给客户端的包数量保持在最低限度。
所以我们的想法是仅在向后兼容性更改时重置错误修复编号。使用这种逻辑，我们可以创建一个自动系统，该系统仅在客户端已安装的版本发生任何错误更改且符合新前端 (FE) 要求时才会生成新包。
为了更好地展示这一切，这里有几个例子：
递增逻辑
需要包决策逻辑
虽然这是一个非标准的版本控制逻辑，你们觉得这个逻辑有什么问题吗？
【问题讨论】：
标签： java version versioning product
只要您有整个公司都理解并遵守的内部逻辑，跳过版本号（或使用复杂的版本号）就没有问题。 （如果事情没有改变……微软将跳过其 Windows 系统的第 9 版。）
[major].[minor].[release].[build] 被许多公司大量使用。
在我们公司，我们在 [build] 之外添加了一个称为 [private] 的额外功能。
[major].[minor].[release].[build].[private]
在我们的逻辑中，[private] 用于错误测试的内部排序。 （我们故意破坏我们的代码，以便我们可以测试错误。）但在发布代码之前，必须将 [private] 设置回零。因此，除非版本号末尾有一个 .0，否则任何代码都不会离开办公室。提醒程序员删除（或注释掉）他们的测试代码并且提醒测试人员不要发送仅用于测试的代码。
早在 80 年代，我还阅读了一些关于版本编号心理学的文章。一些公司会直接跳到 [次要] 第 3 版，只是为了让它看起来他们做了比实际做的更多的测试。他们还避免超过 7，因为这让他们看起来像是在修复太多错误并且容易出现可怕的错误代码。这种对客户或客户的心理感知可能相当强烈，并且可能会在程序员（他们往往是正确的字面主义者）和营销人员（他们将逻辑视为经过深思熟虑的蓬松）之间发生巨大的争论。
考虑到这一点，回答您的问题：您的逻辑太棒了……现在把它卖给您的营销部门。 （或者更好的是……不要把它卖给他们，只是实施它，希望他们不要敲你的门、隔间或藏身之处。）
祝您的设计好运。 :)
【讨论】：
[major].[minor].[release].[build] （这篇文章被广泛接受的模式：https://stackoverflow.com/a/615277/758378）
您这样做是有特定原因的，所以我认为没有任何问题。 （你的具体逻辑对我来说也很好。）
这根本不是问题。在上面链接的答案中，您甚至可以看到使用 SVN 修订作为建议使用的数字。
【讨论】：