确定版本号答案

【问题标题】：Deciding on version numbers确定版本号
【发布时间】：2009-03-06 16:23:12
【问题描述】：

复制

你好，

所以我最近看到 Groovy 已发布到版本 1.6，在收听 Java Posse 播客时，他们评论说这个版本中包含了如此多的内容已经是 2.0 版本。

这让我开始思考。版本号是任意的吗？我曾经认为它们是有意义的，但我想不是。这一切都只是基于里程碑并将项目设置为项目吗？

您的团队如何控制您的版本号和发布？

提前致谢

【问题讨论】：

【解决方案1】：

区分用于营销的版本控制和用于技术用途的版本控制。

对于营销，答案是：“无论您希望客户怎么想。”在这种情况下，“主要新版本”可能应该伴随着主要版本号。

另外请注意，细心的客户在使用“主要”新版本之前会犹豫不决，直到他们在测试环境中尝试过。 “构建更改”版本被认为具有错误修复和其他不需要太多安装过程的小东西。

用于技术用途，答案是：“您想为开发人员编码的任何信息。”没有一种正确的方法可以做到这一点。这取决于你的目标。

也许“主要”版本意味着“可能意味着大量新错误的重大更改”。也许每次编译都会出现一个新的“构建”号。也许按日期的每晚构建标签是您的版本。您可以基于时间、Scrum 周期、里程碑、功能等等！

【讨论】：

【解决方案2】：

他们非常随意。很多人都喜欢这样的东西

[major].[minor].[release].[revision]

作为他们的版本控制计划，但我也曾在一些公司因为其中一位 VP 不想发布而拒绝发布 1.0 品牌产品。营销也可以影响这一点。

增加主要版本的一个好问题可以是：

如果这是付费产品，客户是否会付费升级到这个新版本？

如果是这样，最好增加主编号。

【讨论】：

【解决方案3】：

MajorRelease.MinorRelease.Hotfix

【讨论】：

【解决方案4】：

版本号是任意的，但有一些经验法则（我认为）。非常小的更改或错误修正通常会增加 0.0.1，即 V1 变为 V1.0.1。对功能的微小更改增加了 0.1.0，即 V1.0.1 变为 V1.1.0。重大更改或重写会增加 1.0.0，即 V2。

也就是说，许多公司似乎试图通过将 0.1.0 的类似变化提高 1.0.0 来说服客户某些重要的事情。此外，一些依赖支持合同的公司将免费提供 0.1.0 更新，但对 1.0.0 更新收费。

另外，IIRC，一些项目倾向于将奇数版本的实验版本和稳定版本表示为偶数版本，（因此 V3 很危险，V4 是稳定的）。

【讨论】：

【解决方案5】：

如果是库，版本号会告诉您两个版本之间的兼容性级别，以及升级的难度。

错误修复版本需要保留二进制、源代码和序列化兼容性。

次要版本对不同的项目意味着不同的东西，但通常它们不需要保持源代码兼容性。

主要版本号可以打破所有三种形式。

我写了更多关于理由here。

【讨论】：