您推荐什么版本编号方案? [英] What version numbering scheme do you recommend?

问题描述

我的问题是，哪种版本命名方案应该用于什么类型的项目.

My question is, which version-naming scheme should be used for what type of project.

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

Very common is major.minor.fix, but even this can lead to 4 number (i.e. Firefox 2.0.0.16). Some have a model that odd numbers indicate developer-versions and even numbers stable releases. And all sorts of additions can enter the mix, like -dev3, -rc1, SP2 etc.

存在偏爱一种方案而不是另一种方案的原因，不同类型的项目(即开源与闭源)是否应该有不同的版本命名方案?

Exists reasons to prefer one scheme over another and should different type of projects (i.e. Open Source vs. Closed Source) have different version naming schemes?

推荐答案

对此有两个很好的答案(加上很多个人喜好；请参阅 Gizmo 对宗教战争的评论).

There are two good answers for this (plus a lot of personal preferences; see gizmo's comment on religious wars).

对于公共应用程序，标准的Major.Minor.Revision.Build 在 IMO 中效果最好 - 公共用户可以轻松地知道他们拥有的程序版本，对于某些人来说度，他们的版本有多远.

For public applications, the standard Major.Minor.Revision.Build works best IMO - public users can easily tell what version of the program they have and, to some degree, how far out of date their version is.

对于内部应用程序，用户从不要求应用程序，部署由 IT 处理，用户将呼叫帮助台，我找到了 Year.Month.Day.Build 在很多情况下都能更好地工作.因此，可以对该版本号进行解码，以向帮助台提供比公共版本号方案更有用的信息.

For in house applications, where the users never asked for the application, the deployment is handled by IT, and users will be calling the help desk, I found the Year.Month.Day.Build to work better in a lot of situations. This version number can thus be decoded to provide more useful information to the help desk than the public versioning number scheme.

但是，在一天结束时，我会提出一个高于一切的建议 - 使用可以保持一致的系统.如果有一个系统可以设置/编写编译器每次自动使用的脚本，请使用.

However at the end of the day I would make one recommendation above all else - use a system you can keep consistent. If there is a system that you can setup/script your compiler to automatically use everytime, use that.

可能发生的最糟糕的事情是您发布了与之前版本号相同的二进制文件 - 我最近一直在处理自动网络错误报告(其他人的应用程序)，并得出的结论是 Year.Month.Day.Build 版本号显示在核心转储中，其中甚至不是应用程序本身的远程最新版本(应用程序本身使用带有实数的闪屏 - 当然，这不是从二进制文件中提取的，正如人们所假设的那样).结果是我无法知道故障转储是来自 2 年旧的二进制文件(版本号表示什么)还是来自 2 个月旧的二进制文件，因此无法获得正确的源代码(也没有源代码控制！)

The worst thing that can happen is you releasing binaries with the same version number as the previous ones - I've recently been dealing with automated network error reports (someone elses application), and came to the conclusion that the Year.Month.Day.Build version numbers shown in the core dumps where not even remotely up to date with the application itself (the application itself used a splash screen with the real numbers - which of course where not drawn from the binary as one might assume). The result is I have no way of knowing if crash dumps are coming from a 2 year old binary (what the version number indicates) or a 2 month old binary, and thus no way of getting the right source code (no source control either!)

这篇关于您推荐什么版本编号方案?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！