我的问题是，哪种版本命名方案应该用于哪种类型的项目。
很常见的是major.minor.fix，但即使这样也可能导致4个数字(即Firefox 2.0.0.16)。有些模型的奇数表示开发人员版本，偶数表示稳定版本。并且各种添加都可以加入其中，例如 -dev3、-rc1、SP2 等。
是否有理由选择一种方案而不是另一种方案，不同类型的项目(即开源与闭源)是否应该有不同的版本命名方案？
最佳答案
对此有两个很好的答案(加上很多个人喜好；请参阅小发明对宗教 war 的评论)。
对于公共(public)应用程序，标准的Major.Minor.Revision.Build在我看来效果最好 - 公共(public)用户可以轻松地知道他们拥有的程序版本，并且对某些人来说程度，他们的版本有多过时。
对于内部应用程序，用户从未要求过应用程序，部署由 IT 部门处理，用户将调用帮助台，我找到了Year.Month。 Day.Build 在很多情况下都能更好地工作。因此，可以对该版本号进行解码，以便为帮助台提供比公共(public)版本号方案更有用的信息。
但是最终我会提出一个最重要的建议 - 使用可以保持一致的系统。如果有一个系统可以让您的编译器每次都自动使用，使用该系统。
可能发生的最糟糕的事情是您发布了与以前的版本号相同的二进制文件 - 我最近一直在处理自动网络错误报告(其他人的应用程序)，并得出结论，Year.Month核心转储中显示的 .Day.Build 版本号甚至与应用程序本身都不是最新的(应用程序本身使用带有真实数字的启动屏幕 - 当然，这不是像人们想象的那样从二进制文件中提取的)。结果是我无法知道故障转储是否来自 2 年前的二进制文件(版本号表示的内容)或 2 个月前的二进制文件，因此无法获取正确的源代码(也没有源代码控制! )
关于versioning - 您推荐什么版本编号方案？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/121795/