快速的主要版本是设计不良的证据吗？

Question

几个月前我开始做初级程序员。我们正在研制的这个系统已经生产了两年。我没有参与系统和设计的乞求。

有一件事我注意到，系统的主要版本已经是11.Y.Z。根据我与其他系统和库的工作经验，我不记得看到一个产品的主要版本跳得那么快。有些产品已经在1.X.Y中使用了多年，并且仍然在接受特性和错误修复。

假设语义版本化使用得当，这是否表明系统设计不当，因为它几乎每四个月进行一次重大的破坏更改？

Answer 1

假设语义版本使用得当，这是否表明系统设计不当，因为它几乎每四个月进行一次重大的破坏性更改？

不一定。

您在注释中提到，这是一个内部API。破坏API是不好的，因为你破坏了每个人的代码。但是对于内部API来说，“每个人”只是“您”，而且您完全能够与自己协调这些API更改，因此通常与API更改相关的痛苦要轻得多。

而且，平均水平可能会产生很大的误导性:也许在早期开发的头几天中，它们发生了11次破坏API的变化，并且从那以后已经稳定了4年了？如果主号为0，SemVer允许您在不增加主数值的情况下进行中断更改，但它不会强迫您这样做。也许他们从第0天就开始使用SemVer了，甚至在原型开发/探索阶段？

Answer 2

短答案

No

长答案

“有时一个数字只是一个数字”

关于当前疯狂世界中的“语义版本化”、“合理性”、“逻辑”的忘却

为什么Chrome会这么快地吞噬版本号呢？

“版本”数字被用作分支点的里程碑，而不是其他开发人员使用它们的方式来吸引公众的重大发布。这是一个持续的开发流程，功能已经准备好或没有准备好，而不是偶尔发生的事件，将许多新特性聚集在一起，使大事件发生

Answer 3

在使用语义版本控制时，仍然需要决定哪些更改被认为是“重大”的，哪些是“次要的”。增加版本号，或者不加版本号，有多种原因。

具有向后兼容性承诺的系统最终可能会在大多数更新中增加主版本号，这仅仅是因为在一些或多或少深奥的角落情况下，存在向后兼容性中断。同样的系统可能几乎不确定地坚持1.x.y，因为大量的努力都是在向后兼容性，试图永远不破坏任何依赖的系统。这两种版本编号方法都可以被认为是“保守的”，但这两种方法都可能是一个深层次问题的迹象。

其他情况下，您实际上有一个发布计划(想想发送给客户的季度更新CD)，其中更改主要版本号是有意义的，因此它只说“11.0版”，而不是“3.4 /10月16日版本”。如今，越来越多的软件在短时间内发布，使得发布计划不再成为坚持特定版本控制方案的理由。我在大型仓库系统中看到过这种情况，它只允许内部IT在四分之一的时间(通常是周日)停机一天。这一天是部署日，每次都会标记一个新的主要版本。

有些程序具有最重要的外部依赖性，因为用户必须同时更新这两个方面。如果您有一个只适用于Word 2010和另一个用于Word 2013的单词-addon，您可能希望将您的主要版本号与MS-Word的版本号同步。在这里，主要数字是如此重要，因为您的一些用户将“落后”您的正常更新计划，因为他们还没有更新到最新版本的Word (或其他您所依赖的东西: SAP、Dynamic等)。

有时，其他外部因素决定版本号。如果你有财政软件，可能会有与税法相对应的年度更新(通常在1月1日生效)。这类系统的主要版本将每年精确地改变一次--这并不是因为这是更新时间表，而是因为这对客户来说是另一件重要的事情:如果你做了2016年的税收，你最好有程序更新到2016年的税法。

最后，版本号依赖于许多因素--通常是特定于一个域--因此仅靠版本号并不能告诉您任何关于代码库状态的信息。这是一种更好的方法来研究部署何时、为什么和如何发生--以及部署进展如何顺利。如果你能向10.000名客户推出一次重大更新，并打几个电话--你可能会没事。如果你向10个客户推出了一个小补丁，并因此不得不加班，那么可能是出了问题。