你推荐什么版本的编号scheme？
我的问题是，哪个版本命名scheme应该用于什么types的项目。
很常见的是major.minor.fix，但即使这样也会导致4个数字（例如Firefox 2.0.0.16）。 有些模型的奇数表示开发者版本，甚至数字稳定版本。 而且各种补充可以进入混合，如-dev3，-rc1，SP2等。
存在的理由是更喜欢一个scheme而不是另一个scheme，并且不同types的项目（即开放源代码和封闭源代码）是否有不同的版本命名scheme？
有两个很好的答案（加上个人喜好，请参阅Gizmo对宗教战争的评论）
对于公共应用程序，标准的Major.Minor.Revision.Build最适合海事组织 – 公众用户可以很容易地知道他们有什么版本的程序，在某种程度上，他们的版本有多远。
对于内部应用程序，用户从未请求应用程序，部署由IT处理，用户将打电话给帮助台，我发现Year.Month.Day.Build在很多情况下都能更好地工作。 这个版本号可以被解码，以便向服务台提供更多有用的信息，然后提供公共版本号scheme。
然而在一天结束的时候，我会首先做一个推荐 – 使用一个可以保持一致的系统 。 如果有一个系统，你可以设置/脚本编译器自动使用每一次， 使用它 。
可能发生的最糟糕的事情是，你发布的版本号与之前版本号一样 – 我最近一直在处理自动networking错误报告（某人elses应用程序），并得出结论，Year.Month.Day。构build核心转储中显示的版本号，甚至不会与应用程序本身保持最新状态（应用程序本身使用带有实际数字的启动屏幕 – 当然这不是从二进制文件中绘制出来的）。 结果是我无法知道崩溃转储是来自一个2岁的二进制文件（版本号表示）还是2个月大的二进制文件，因此没有办法获得正确的源代码（也没有源代码控制！ ）
以下是我们公司使用的内容： 重大 。 轻微 。 补丁版本 。 内部编号 。
主要的变化包括一个完整的发布周期，包括市场参与等。这个数字是由研发部门之外的力量控制的（例如，在我工作的一个地方，市场部门决定我们的下一个版本是'11' – 匹配竞争对手，当时我们在第2版:)）。
将新function或主要行为更改添加到产品时， 轻微更改。
每次修补程序正式添加到版本时，修补程序版本都会上升一次，通常只包括错误修复。
构build版本用于为客户发布特殊版本，通常是针对特定的错误修复。 通常，修补程序将在下一个修补程序或次要版本中汇总（而产品pipe理通常将该错误标记为“将在我们的跟踪系统中针对修补程序3发布”）。
我们的研发部门使用1.0.0.0.0.000：MAJOR.minor.patch.audience.critical_situation.build
请， 请不要这样做。
我是语义版本的忠实粉丝
正如许多其他人所评论的，这使用了XYZ格式，并给出了很好的理由。
这种问题比宗教方面更多的是宗教战争。 对于编号scheme或其他编码scheme总是有很多优点和缺点。 所有人可以（或应该）给你的是他们使用的scheme，以及他们为什么select它。
在我身边，我使用了一个XYZscheme，所有的数字都在这里：
- X表示引入后向不兼容的公共API的变化
- Y表示增加了一些function
- Z表示修复（修复一个bug，或者改变内部结构而不影响function）
最终，如果我想在官方发布之前得到用户的反馈，我会使用“Beta N”后缀。 没有“RC”后缀，因为没有人是完美的，总会有错误;-)
以前的讨论可能会有帮助。
我个人比较喜欢MAJOR.MINOR.BGFGF-SUFFIX，其中SUFFIX是开发版本（版本控制签出）的开发者， rc1 / rc2是候选版本，没有发行版本的后缀。
如果你有开发结账的后缀，甚至可能带有修订版本号，那么就没有必要让它们变成偶数/奇数，以使它们分开。
在库的情况下，版本号会告诉您两个版本之间的兼容性级别 ，因此升级将有多困难。
错误修复版本需要保持二进制，源代码和序列化兼容性。
次要版本对于不同的项目意味着不同的东西，但通常它们不需要保持源代码兼容性。
主版本号可以打破所有三种forms。
我在这里写了更多关于这个理由的文章。
我们更喜欢major 。 minor milestone 。 revision – buildscheme，其中：
-
major：在重大的架构变化或能力的重要进步时增加。 -
minor：小改动和新function，不需要架构改变。 -
milestone：表示代码的稳定性和成熟度：- 0开发/ pre-alpha
- 1为阿尔法
- 2为testing版
- 3候选发行（RC）
- 4最后/生产版本
-
revision：表示版本，补丁或错误修复号码。 -
build：对应用程序的特定构build或版本的唯一引用。 内部版本号是一个顺序整数，通常在每个版本中增加。
例子：
-
1.4.2.0-798：版本1.4第一个beta版本，由版本号798创build。 -
1.8.3.4-970：1.8-RC4，由内部版本号970创build。 -
1.9.4.0-986：版本1.9第一个生产版本，由版本号986创build。 -
1.9.4.2-990：版本1.9第二个1.9.4.2-990版本，由版本号990创build。
由于生产版本在版本string的第三位总是有4个，因此生产版本可能会删除该数字。
有了敏捷软件开发实践和SaaS应用程序，主要版本和次要版本的想法已经消失 – 版本的发布非常频繁，所以依赖于这个区别的版本编号scheme对我来说已经不再有用了。
我的公司使用一个编号scheme，该编号scheme在发行开始的一年中的最后两位数字后面跟随该年的版本号码。
因此，2012年开始的第四次发布将是12.4。
如果需要的话，你可以包含一个“错误修正”版本号，但理想情况下，你要经常发布这些并不经常需要的东西 – 比如“12.4.2”。
这是一个非常简单的scheme，并没有给我们任何我以前使用的其他版本编号scheme的问题。
closures和开源版本号政策之间的差异也可以来自商业方面 ，当主要版本可以反映发布的年份时。
我们以前在这里做的是major.minor.platform.fix 。
主要 ：我们增加这个数字时，从这个构build保存的文件不再兼容以前的构build。
例 ：3.0.0.0版保存的文件与2.5.0.0版不兼容。
轻微 ：我们增加了这个数字，当一个新的function已被添加。 该function应该由用户看到。 不是开发者隐藏的function。 当major增加时，这个数字被重置为0。
平台 ：这是我们用于开发的平台。
例如 ：1代表.net框架版本3.5。
修复 ：当只有错误修复包含在这个新版本中时，我们增加这个数字。 当主或次增加时，这个数字被重置为0。
只是
Major.Minor.Revision.Build
