我的问题是，哪种类型的命名方案应用于哪种类型的项目。

major.minor.fix很常见，但即使这样也会导致4个数字(即Firefox 2.0.0.16)。有些模型的奇数表示开发人员版本，偶数表示稳定版本。并且各种添加项都可以加入混合，例如-dev3，-rc1，SP2等。

是否有理由偏爱一种方案而不是另一种方案，并且不同类型的项目(即开源与封闭源)是否应具有不同的版本命名方案？

解决方案

我个人更喜欢MAJOR.MINOR.BUGFIX-SUFFIX，其中SUFFIX对于开发版本(版本控制签出)为dev，对于发行候选为rc1/rc2，对于发行版本没有后缀。

如果我们有用于开发结帐的后缀，即使有修订号，也无需使它们成偶/奇数以使它们分开。

封闭版本和开源版本号策略之间的差异也可能来自商业方面，例如主版本可以反映发行年份。

这种问题更多地是关于宗教战争，而不是客观方面。总是有很多利弊反对编号方案或者其他。人们可以(或者应该)给一切就是他们使用的方案以及为什么选择它。

在我这边，我使用X.Y.Z方案都是数字，其中：

• X表示公共API中的更改会导致向后不兼容
• Y表示某些功能的添加
• Z表示修复(修复错误，或者更改内部结构而不影响功能)

最终，如果要在正式发布之前从用户那里得到一些反馈，我会使用" Beta N"后缀。没有" RC"后缀，因为没有人是完美的，并且总会有bug ；-)

这是我们在公司中使用的：Major.Minor.Patch version.Build Number。

重大更改涉及整个发布周期，包括市场营销等。
这个数字是由研发部门以外的力量控制的(例如，在我工作过的地方之一，市场部决定我们的下一个版本为" 11"，以与竞争对手匹敌。当时是第2版)：)。

将新功能或者主要行为更改添加到产品后，次要更改。

每次正式向版本添加补丁时，补丁版本都会增加一个，通常仅包括错误修复。

当为客户发布特殊版本时，通常会使用特定于他的错误修复程序来使用内部版本。通常，该修补程序将汇总到下一个补丁程序或者次要版本(并且产品管理通常在跟踪系统中将错误标记为"将针对补丁程序3发布")。

我们的研发部门使用1.0.0.0.0.000：MAJOR.minor.patch.audience.critical_situation.build

拜托，拜托，不要那样做。

我们以前在这里做的是major.minor.platform.fix。

major：当此版本中保存的文件不再与以前的版本兼容时，我们增加此数字。
例如：版本3.0.0.0中保存的文件与版本2.5.0.0不兼容。

小调：添加新功能后，我们会增加此数字。用户应该可以看到此功能。这不是开发人员的隐藏功能。当专业增加时，此数字重置为0。

平台：这是我们用于开发的平台。
示例：1代表.net Framework 3.5版。

fix：当此新版本中仅包含错误修复程序时，我们将增加此数字。当主要或者次要递增时，此数字重置为0。

简单地

Major.Minor.Revision.Build

有两个很好的答案(加上很多个人喜好，请参见gizmo对宗教战争的评论)

对于公共应用程序，标准的Major.Minor.Revision.Build最适合IMO公共用户可以轻松地知道他们拥有该程序的哪个版本，并且在某种程度上可以看出它们的版本有多旧。

对于内部应用程序，用户从未要求过该应用程序，部署由IT处理，并且用户将致电服务台，我发现Year.Month.Day.Build在许多情况下都可以更好地工作。因此，可以对该版本号进行解码，以向服务台提供比公共版本号方案更多的有用信息。

但是，归根结底，我会首先提出一个建议，即使用可以保持一致的系统。如果存在可以设置/编写编译器以使其每次自动使用的系统，请使用该系统。

可能发生的最糟糕的事情是，我们发布的二进制文件的版本号与我最近处理自动化网络错误报告(其他应用程序)时使用的版本号相同，并得出Year.Month.Day.Build的结论。核心转储中显示的版本号甚至没有远程更新到应用程序本身(应用程序本身使用了带有真实数字的启动画面，当然，实际数字并不是假定的二进制数)。结果是我无法知道崩溃转储是来自2年的二进制文件(版本号表示)还是2个月的二进制文件，因此也就无法获取正确的源代码(也没有源代码控制！ )

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

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

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

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

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