isdn电话编号方案_版本编号方案–另一种方法

isdn电话编号方案

版本编号方案可能是我们软件工程师所拥有的除排序算法之外的少数事物之一。 但是，总有更多空间。

尽管MAJOR.MINOR.PATCH的经典方法（例如1.8.2 ）对于以广泛方式分发的库或产品非常有效，但它仍然不像看起来那样容易。 有什么重大变化 ？ 什么未成年人 ？ 1.9之后会怎样？ 2.0或1.10 ？ 许多例子都证明了这种经典方法的失败，Java是最著名的例子之一。

另一方面，这种方法几乎完全适合于库，因为这里的规则非常明显：

• 为每个发行版增加次要版本（ 2.4-> 2.5 ）
• 进行向后不兼容的更改时增加主要版本（ 2.4-> 3.0 ）
• 增加每次更新的补丁程序级别，这只会修复错误，但没有添加功能（ 2.4-> 2.4.1 ）

但是，对于在云中运行或仅交付给许多客户的软件，区别并不总是那么明显。 由于我们不区分次要更新还是主要更新（ 请问销售人员，每个版本都是向前迈出的重要一步 ），因此我们最终使用了我们的内部版本号
Jenkins构建服务器作为版本号。

尽管此方法效果很好，但存在两个问题：

1. 您需要一个发布连续的内部版本号的内部版本服务器
2. 如果不查看构建服务器，就无法确定发布的时间（ BUILD-51比BUILD- 52多大了？ ）

因此，我们现在开始转向基于SIRIUS的产品的另一种方法：受IC上日期代码的启发，我们开始在发行版中使用相同的代码。 日期代码由四位数字组成，前两位是年份，后两位是星期号。 因此，此博客文章的版本为1406 。

由于我们每周执行的发布不止一个，因此版本号始终是唯一的。 此外，这些数字非常短且容易记住（与foo-20130527之类的完整日期相比）。 他们仍然提供有关发布日期的粗略信息。

现在，正如我所说，该方案并不比其他方案优越。 这只是解决我们问题的好方法。 如果喜欢，请使用它，否则请忽略它！

参考： 版本编号方案–我们的JCG合作伙伴 Andreas Haufler在Andy的软件工程专栏博客中的另一种方法 。

翻译自: https://www.javacodegeeks.com/2014/02/version-numbering-scheme-yet-another-approach.html

isdn电话编号方案