我在线分发软件，并且总是想知道是否存在适当的方法来更好地定义版本号。

让我们假设答案中有A.B.C.D。我们何时增加每个组成部分？

我们是否使用了其他任何版本编号技巧，例如D mod 2 == 1意味着它仅是内部发行版？

我们是否有带有自己版本号的beta版本，或者每个版本号都有beta版本？

解决方案

我使用V.R.M例如2.5.1

V(版本)更改是主要的重写
R(修订)更改是重要的新功能或者错误修复
M(修改)更改是次要的修正(打字错误等)

有时我有时也会在末尾使用SVN提交编号。

我们的政策：

• A-功能或者界面上的重大更改(> 25％)。
• B-功能或者界面上的微小更改或者添加。
• C-破坏界面的微小更改。
• D-修复了不更改界面的内部版本。

人们倾向于使这一过程变得比实际需要的困难得多。如果产品只有一个长期存在的分支，则只需使用其内部版本号来命名连续的版本。如果我们有某种"较小的错误修复是免费的，但我们必须支付主要的新版本"，则请使用1.0、1.1 ... 1.n，2.0、2.1 ...等

如果我们不能立即计算出示例中的A，B，C和D，那么我们显然不需要它们。

我通常使用D作为构建计数器(由编译器自动递增)
每次将构建发布到" public"时，我都会递增C(并非每个构建都发布)
A和B用作主要/次要版本号，并已手动更改。

我认为有两种方法可以回答这个问题，它们并不完全是互补的。

• 技术：根据技术任务增加版本。示例：D是内部版本号，C是迭代，B是次要版本，A是主要版本。定义次要版本和主要版本确实是主观的，但可能与诸如更改基础体系结构等相关。
• 市场营销：根据向客户提供了多少"新"或者"有用"功能，增加版本。我们也可以将版本号与更新策略绑定在一起...对A的更改要求用户购买升级许可证，而对其他更改则不需要。

我认为，最重要的是找到一种适合我们和客户的模型。我见过一些情况，偶数版本是公共发行，奇数版本被视为Beta或者dev发行。我看过一些产品，它们一起忽略了C和D。

然后是Micrsoft的示例，其中对.Net Framework版本号的唯一合理解释是涉及到Marketing。

我唯一使用过的版本号是让客户可以告诉我他们正在使用版本2.5.1.0或者其他版本。

我唯一的规则是设计用于最大程度地减少报告该数字时的错误：所有四个数字都只能为1位数字。

1.1.2.3

可以，但是

1.0.1.23

不是。客户可能会将两个数字(至少在口头上)报告为"一对一三二"。

自动递增的内部版本号通常会导致版本号如下

1.0.1.12537

这也没有真正的帮助。

对于内部开发，我们使用以下格式。

[Program #] . [Year] . [Month] . [Release # of this app within the month]

例如，如果我今天发布应用程序15，并且这是本月的第三次更新，那么我的版本将是

15.2008.9.3

这完全是非标准的，但对我们很有用。

对于过去的六个主要版本，我们使用了M.0.m.b，其中M是主要版本，m是次要版本，b是内部版本号。因此发布的版本包括6.0.2、7.0.1，...，直至11.0.0。不要问为什么第二个数字总是为0。我问过很多次，没有人真正知道。自从5.5在1996年发布以来，我们还没有出现过非零值。

我开始喜欢某些应用程序(例如Perforce)使用的Year.Release [.Build]约定。基本上，它只是说出我们发布的年份以及该年内的顺序。因此，2008.1将是第一个版本，如果我们再发布一个月或者三个月后，它将发布到2008.2.

这种方案的优点是没有隐含的发布"数量级"，我们可以在其中争论某个功能是否足够主要以保证主要版本的增加。

可选的添加功能是标记内部版本号，但这往往仅出于内部目的(例如添加到EXE / DLL中，以便我们可以检查文件并确保正确的内部版本)。

一个好的非技术方案只使用以下格式的生成日期：

YYYY.MM.DD.BuildNumber

其中BuildNumber是连续数字(更改列表)或者仅从每天1开始。

例如：2008.03.24.1或者2008.03.24.14503

这主要用于内部发行，如果我们每月发行的频率不超过一次，则公开发行的版本将显示为2008.03. 维护版本的标记为2008.03a 2008.03b，依此类推。他们很少应该超过" c"，但是如果这样做是一个很好的指标，则我们需要更好的质量保证和/或者测试程序。

用户通常看到的版本字段应以友好的" 2008年3月"格式打印，在"关于"对话框或者日志文件中保留更多技术信息。

最大的缺点：在另一天只编译相同的代码可能会更改版本号。但是我们可以通过使用版本控制更改列表作为最后一个数字并检查该数字以确定是否还需要更改日期来避免这种情况。

在我看来，几乎任何发行号方案都可以或者多或者少地合理地工作。我使用的系统使用的版本号是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 if VERSION> 900`测试，而不必这样做：if(VERSION> = 900 ||(VERSION> = 280 && VERSION <400)，其中我用9.00乘900表示9.00版本。然后在3.00.xC3版本中引入了重大更改-我的方案无法在次要发行版级别上检测到更改。 ..

注意：埃里克·雷蒙德(Eric Raymond)提供了《软件发行实践》 HOWTO，其中包括(命名的)版本编号的(链接的)部分。

在一天结束时，这完全是主观的，只取决于我们自己/团队。

只是看看所有已经完全不同的答案。

我个人使用Major.Minor。*。*，其中Visual Studio自动填写修订/内部版本号。这也是在我工作的地方使用的。

此Apple技术说明中描述了一种源自旧Mac OS的良好的用户友好版本控制方案：http://developer.apple.com/technotes/tn/tn1132.html

我喜欢Year.Month.Day。因此，v2009.6.8将是本文的"版本"。无法(合理地)复制，并且很清楚什么是较新的发行版。我们也可以删除小数点并将其设置为v20090608.

对于库，版本号告诉我们两个发行版之间的兼容性级别，以及升级的难度。

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

次要发行版对不同的项目意味着不同的事情，但是通常它们不需要保持源兼容性。

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

我在这里写了更多关于基本原理的文章。