快速的主要版本是否表明设计不良？

16

几个月前，我开始担任初级程序员的工作。我们正在研究的系统已投入生产约2年。我没有参与系统和设计的乞讨。

我注意到的一件事是，系统主要版本已经是11.YZ。根据我在其他系统和库上的使用经验，我不记得看到如此快的产品碰撞主要版本的情况。有些产品已经在1.XY中使用多年，并且仍在接收功能和错误修正。

假设正确使用了语义版本控制，这是否表明系统设计不佳，因为它几乎每四个月进行一次重大更改？

versioning semantic-versioning

— 用户名
source

2

这个问题将取决于那些重大的重大变化是否带来了足以证明高变化率的正当利益（和利润）。

— rwong

3

如果该版本号使用Semver，并且系统具有其他团队或组织所依赖的库或其他API，那么这个较高的主要数字意味着在进行稳定，可扩展的API设计方面存在问题。这也意味着清楚地传达不兼容问题是非常重要的。对于其他任何内容（例如市场名称，应用程序，非Simver编号，等等），该编号都是没有意义的，应在很大程度上予以忽略。只需向您的同事询问，这是您更好地了解该项目的一部分。

— 阿蒙（Amon）

3

@amon该系统在内部与通过类似REST的API与系统通信的公共移动客户端一起使用。正如我提到的那样，版本控制是Semver，而不是市场营销版本。

— user367035

数字无关紧要，但是如果版本标识符包含一些可爱的首字母缩写，例如Windows NT或Windows ME或XP或真正的Windows，我会感到怀疑。

— John Wu

1

@JohnWu：问题是关于数字的，所以，是的，数字确实很重要。更确切地说，它是关于SemVer，其中数字不仅上下文的数量确实此事，但也有一个精确指定的含义。

— 约尔格W¯¯米塔格

14

假设正确使用了语义版本控制，这是否表明系统设计不佳，因为它几乎每四个月进行一次重大更改？

不必要。

您在评论中提到这是一个内部API。破坏API是不好的，因为您破坏了每个人的代码。但是对于内部API，“每个人”就是“您”，您完全有能力与自己协调此类API更改，因此，通常与API更改相关的痛苦要轻得多。

此外，平均数可能会产生巨大的误导作用：也许他们在早期开发的前几天就进行了11次API重大更改，并且从那时起已经稳定了4年？如果主号码为0，SemVer 允许您在不增加主号码的情况下进行重大更改，但这并不强迫您这样做。也许他们从第0天开始就使用SemVer，甚至在原型设计/探索阶段也是如此？

— 约格·米塔格
source

5

这个答案似乎直接解决了这个问题。如果不是OP的语义版本控制假设，则其他一些答案将是有效的。

— joshp

同样值得注意的是，突破性变化并不总是那么重要。有时它们确实很小（但很重要）。因此，对于用户而言，他们几乎不需要任何更改。同样，根据API的使用方式，可能会有很大程度的重大更改。例如，有时重大更改不会影响所有用户。而且，错误修复可能会引入重大更改，但理想的是尽快而不是稍后进行修复。而且，如果API是内部的，则处理这些小的重大更改要容易得多。

— 吉

1

简短答案

没有

长答案

“有时数字只是数字”

忘记当前疯狂世界中的“语义版本控制”，“合理性”，“逻辑”

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

“版本”数字用作分支点的里程碑，而不是主要发行版，以吸引其他开发者使用它们的方式向公众传播。这是一个持续的开发流程，功能已经准备好或尚未准备好，而不是偶尔的事件，它将许多新功能整合在一起，形成了一个大事件

— 懒Bad
source

7

OP表示他们正在使用语义版本控制。您为什么然后忽略它？

— 约尔格W¯¯米塔格

-3

当使用语义版本控制时，仍然需要决定哪些更改被认为是“主要”，哪些更改是“次要”。出于各种原因更改版本号-或不更改版本号。

具有向后兼容性保证的系统可能最终会在大多数更新中增加主要版本号，仅仅是因为在某种程度上有些神秘的极端情况下存在向后兼容性中断。相同的系统几乎可以无限期地坚持1.xy，因为向后兼容性付出了很多努力，试图永不破坏任何从属系统。两种版本编号方法都可以被认为是“保守的”，但是这两种方法也可能表明存在着深层的潜在问题。

在其他时候，您实际上有一个发布时间表（考虑每季度发送给客户的季度更新CD），在该版本中可以更改主要版本号，因此它不是“ Version 3.4 / Oct 16”，而是说“ Version 11.0”。如今，越来越短的间隔内发布了更多的软件，这使得发布计划不再是坚持特定版本控制方案的理由。我已经在大型仓库系统中看到了这一点，该系统只允许内部IT每季度停机一天（通常是星期日）。这一天是部署日，每次都标记有一个新的主版本。

一些程序具有最重要的外部依赖关系，因为用户将必须同时更新两者。如果您有一个仅适用于Word 2010的Word插件，而另一个适用于Word 2013的Word插件，则可能希望将主要版本号与MS-Word的主要版本号同步。在这里，主要数字非常重要，因为您的某些用户尚未更新到Word的最新版本（或您所依赖的其他版本），因此某些用户将落后于正常的更新计划。等等）。

有时，其他外部因素决定了版本号。如果您有财务软件，则可能会有与税法相对应的年度更新（该更新通常在1月1日生效）。此类系统的主要版本每年仅更改一次-不是因为那是更新时间表，而是因为这对客户而言还有其他重要性：如果您执行2016年税法，最好将程序更新为2016年税法。

最后，版本号取决于很多因素（通常特定于一个域），以至于仅版本号不会告诉您有关代码库状态的任何信息。这是查看何时，为什么以及如何进行部署以及部署进行得如何顺利的一种更好的方法。如果您可以向10.000个客户推出主要更新并打几个电话-您可能还不错。如果您向10个客户推出次要补丁程序，并且因此不得不加班，那可能是错误的。

— 哈齐特
source

3

“当使用语义版本控制时，仍然需要决定哪些更改被认为是“重大”更改，哪些是“次要”更改。” –不，没有；在规范中精确定义。“出于各种原因，可以更改版本号-或不更改它。” –不，没有；确切地说，有一个增加主号码的原因（这个问题是关于此问题的），并且在规范中对此进行了精确定义。

— 约尔格W¯¯米塔格

1

@JörgWMittag我读错了，或者规范特别说明了何时必须更改版本号，但它并没有说明您何时可以使用。

— Hazzit

-4

关于版本号含义的共识确实是major.minor.revision.buildnumber

如果专业快速上升，那可能就是开发人员拥有了所有这些新想法并且真的很努力。

但是，在商业世界中，可能还有其他原因需要增加主版本号。喜欢

销售下降，客户/用户正在等待下一个重要的主要版本，然后再进行升级。
合同规定客户有权进行较小的更新。供应商无法向他们收取这些费用，因此将一些小的改进作为主要产品升级出售。
竞争对手X在游戏中的时间更长，因此其主要版本号刚好高于您的主要版本号。这使得您看起来落后了，您必须“追赶”。

— 马丁·马特
source

6

用语义版本标记问题，OP在问题中提及语义版本，并在注释中再次确认他们正在使用语义版本。当主要版本增加时，SemVer规范会非常清楚地说明。您的“其他原因”均不适用。

— 约尔格W¯¯米塔格