获取正确的软件版本号.V1.0.0.1

Question

我在线分发软件,并且总是想知道是否有更好的方法来更好地定义版本号.

让我们假设答案中有ABCD.什么时候增加每个组件？

你使用任何其他版本号技巧,如D mod 2 == 1意味着它只是一个内部发布？

您是否拥有自己版本号的测试版,或者您是否有每个版本号的测试版？

Answer 1

我开始喜欢一些应用程序(例如Perforce)使用的Year.Release [.Build]约定.基本上它只是说你发布的那一年,以及那一年内的顺序.所以2008.1将是第一个版本,如果你在一个月或三个月之后发布另一个版本,它将会发布到2008.2.

这种方案的优点是没有隐含的"大小"的释放,你可以在这里争论一个特征是否足以保证主要版本增量.

可选的额外内容是标记内部版本号,但这往往仅用于内部目的(例如,添加到EXE/DLL,以便您可以检查文件并确保正确构建).

Answer 2

在我看来,几乎任何版本号方案都可以或多或少地保持良好的工作状态.我使用的系统使用版本号,例如11.50.UC3,其中U表示32位Unix,C3是次要修订(修订包)号; 其他字母用于其他平台类型.(我不推荐这个方案,但它有效.)

有一些黄金法则到目前为止尚未说明,但这些法则隐含在人们讨论过的内容中.

• 不要发布两次相同的版本 - 一旦版本1.0.0发布给任何人,它永远不会被重新发布.
• 发布数量应该单调增加.也就是说,版本1.0.1或1.1.0或2.0.0中的代码应始终晚于版本1.0.0,1.0.9或1.4.3(分别).

现在,在实践中,人们确实必须发布旧版本的修复程序,而新版本可用 - 请参阅GCC,例如:

• GCC 3.4.6在4.0.0,4.1.0(和AFAICR 4.2.0)之后发布,但它继续使用GCC 3.4.x的功能,而不是添加添加到GCC 4.x的额外功能.

因此,您必须仔细构建版本编号方案.

另一点我坚信:

• 发行版本号与CM(VCS)系统版本编号无关,除了普通程序.任何具有多个主源文件的严重软件都将具有与任何单个文件的版本无关的版本号.

使用SVN,您可以使用SVN版本号 - 但可能不会因为它变得太不可预测.

对于我使用的东西,版本号是一个纯粹的政治决定.

顺便说一句,我知道从版本1.00到9.53发布的软件,但后来改为2.80.这是一个严重的错误 - 由市场营销决定.当然,该软件的4.x版本已经过时,因此它没有立即引起混淆,但该软件的5.x版仍在使用和销售,并且修订版已经达到3.50.我非常担心当不可避免的冲突发生时,我的代码必须与5.x(旧样式)和5.x(新样式)一起工作.我想我必须希望他们能够在改变到5.x之前直到老5.x真的死了 - 但我并不乐观.我还使用人工版本号(例如9.60)来表示3.50代码,以便我可以进行合理的if VERSION > 900测试,而不必执行以下操作:if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400),其中我代表版本9.00乘900.然后在版本3.00.xC3中引入了重大变化 - 我的方案未能检测到次要版本级别的变化...抱怨...发牢骚......

注意:Eric Raymond提供软件发布实践HOWTO,包括关于命名(编号)版本的(链接)部分.

Answer 3

我通常使用D作为构建计数器(通过编译器自动增加)每次构建发布到"public"时都会增加C(不是每个构建都被释放)A和B用作主要/次要版本号并手动更改.

Answer 4

我认为有两种方法可以回答这个问题,而且它们并非完全互补.

1. 技术:基于技术任务增加版本.示例:D是内部版本号,C是迭代,B是次要版本,A是主要版本.定义次要版本和主要版本确实是主观的,但可能与基础架构的更改有关.
2. 营销:根据为您的客户提供的"新"或"有用"功能的增量版本.您还可以将版本号绑定到更新策略...对A的更改要求用户购买升级许可证,而其他更改则不需要.

我认为,最重要的是找到适合您和您的客户的模型.我见过一些甚至版本都是公开发布的情况,奇数版本被认为是beta或dev版本.我见过一些忽略C和D的产品.

然后是Micrsoft的例子,其中对.Net Framework版本号的唯一合理解释是营销涉及.