您使用什么“版本命名约定”？[关闭]

不同的版本命名约定是否适合不同的项目？您使用什么，为什么？

就我个人而言，我更喜欢以十六进制表示的内部版本号（例如11BCF），该数目应该定期增加。然后为客户提供一个简单的3位数版本号，即1.1.3。

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

我发现自己很少完全同意Jeff Atwood 的观点，但是我倾向于遵循他对.NET版本编号约定的看法。

（主要版本）。（次要版本）。（版本号）。（内部版本号）

对于个人项目，我经常发现这是过大的。我曾在C＃中搜索项目等大型项目中工作过几次，但我坚持使用该约定，并能够有效地将其用作内部跟踪器。

语义版本控制（http://semver.org/）在这里值得一提。它是版本控制方案的公共规范，格式为[Major].[Minor].[Patch]。该方案的动机是用版本号传达含义。

我不使用它，但是我已经看到了，它是一个有趣的结构：

年，月，日，日构建

自我解释。

我尝试使用RubyGems Rational Versioning策略，其中：

• 二进制兼容性损坏时，主要版本号增加
• 添加新功能时，次要版本号增加
• 内部版本号将针对错误修复进行更改。

这是非常细粒度的版本编号方法：

• N.x.K，其中N和K是整数。例如：1.x.0，5.x.1，10.x.33。用于中间版本。
• N.M.K其中N，M和K是整数。例如：1.0.0，5.3.1，10.22.33。用于发行。
• N.x.x，其中N为整数。范例：1.x.x。用于支持分支。
• N.M.x，其中N和M是整数。范例：1.0.x。用于发布分支。

这是用于简单地说明版本编号方法的图片：

PA表示pre-alpha A 表示alpha B 表示beta AR表示alpha释放 BR表示beta释放 RC表示释放候选 ST表示稳定

这种版本编号方法的优点如下：

• 它代表了敏捷软件开发生命周期的细节。
• 它考虑了源代码存储库结构的细节。
• 对于那些习惯了模式的人来说，这是自我解释。每个模式代表不同的工件。可以轻松地解析此类模式并将其用于其他目的，例如问题跟踪。
• 所描述的版本控制方法的基础是版本控制模式集，可用于收集度量标准和计划。
• 它着重于成熟度和质量水平的概念。通常，在没有太多必要的情况下分配了1.0.0这样的版本号（当软件为深alpha版本时）。提出的版本编号方法允许建立多个成熟度级别。在最简单的情况下，它将只有两个级别：中间build（N.x.K）和release（N.M.K）。发布意味着具有完整版本号（N.M.K）的软件已通过供应商公司/组织/团队中的某种质量管理流程。
• 这证明了开发和测试都具有敏捷性。
• 鼓励对软件结构和体系结构采用模块化方法。

还有一个更复杂的图，详细显示了版本控制方法。另外，您可能会找到有用的演示幻灯片，它们描述了向版本控制方法的过渡，以及SCMFViz应用程序，说明了版本编号方法的基本原理。演示幻灯片还解释了为什么在软件项目的整个生命周期中坚持相同的版本控制方法很重要。

我个人对使用日期版本而不是真实版本号的态度是假设软件开发人员使用了过时的版本：

• 对软件开发生命周期一无所知。开发通常是敏捷和迭代的。版本编号方法应代表软件开发过程的迭代性质。
• 不在乎软件质量。质量控制和保证是敏捷和迭代的。就像发展一样。版本号应该是开发和质量控制/保证的敏捷和迭代性质的证明。
• 不在乎其体系结构或应用概念。主版本号（N中的N.M.K）负责体系结构解决方案和应用程序的基本原理。主要版本号N将根据体系结构的更改或主要思想和工作/功能原理的更改而更改。
• 没有控制他们的代码库。大概只有一个分支（主干），它用于所有内容。我个人认为这不对，因为它鼓励代码库成为一个大型垃圾场。

这种方法似乎有点争议，但是我相信这是为软件提供适当版本号的最直接方法。

对于您发布的每个主要版本，在内部都将其称为有效版本并不少见。例如，在我的上一份工作中，我们使用了受Ubuntu启发的以下命名约定来引用主要版本：

[病情] [替代动物名]

其中以“ Limp Lamprey ”，“ Wombed Wombat ”和“ Athmatic Anteater ” 为名。

确保除非它是一个很酷的名称，否则它不会泄漏给您的客户。

Generation.Version.Revision.Build（9.99.999.9999）

世代很少改变。只需打开一个大的产品：DOS-> Windows，即可完成重新设计。

版本用于不兼容的大更改，新功能，软件上某些特定范例的更改等。

经常进行修订（较小的功能和错误修复）。

构建是内部信息。

git describe为您选择的任何编号约定提供了很好的扩展。将其嵌入到构建/打包/部署过程中很容易。

假设您将标记的发行版本命名为ABC（major.minor.maintenance）。git describe在给定的提交上，将找到该提交的最新标记祖先，然后添加此后的提交数量以及该提交的缩写SHA1：

1.2.3-164-g6f10c

当然，如果您实际上使用的是其中一个版本，则只需获取标记（1.2.3）。

这样的好处是，您可以准确地知道自己是从哪个来源构建的，而不必自己为每个单独的构建编号。

Major.Minor.Public（内部）[alpha / beta / trial]，例如“ 4.08c（1290）”

• 以Major为主要版本号（1、2、3 ...）
• 次要版本是2位数的次要版本（01、02、03 ...）。通常，当添加了重要的新功能（仅用于错误修复）时，十位数会递增。
• Public是构建版本（a，b，c，d，e）的公共版本，如果从未将次版本作为公共更新发布，则通常与次版本不同。
• 内部版本号，是编译器跟踪的实际内部版本号。
• 对于这些特殊情况，请附加TRIAL，ALPHA，BETA X或RCX。

我更喜欢分配一些语义的版本号。只要您可以使用版本号来跟踪特定版本报告的错误以对源代码（以及活动管理系统）中发生的更改进行跟踪，那么您就可能使用了正确的方法。

我使用.NET，所以我仍然使用.NET版本编号系统，但是我尝试赋予数字以语义含义，因此

主要，次要，修订版本

• 专业=（取决于项目）
• 次要=（取决于项目）
• build = Hudson的内部版本号（您可以在此处使用TeamCity或TeamBuild等）
• 版本=颠覆或市集修订（取决于项目及其用途）

我们始终确保以某种方式显示版本号（使用基于批处理控制台的程序将其打印到控制台，并显示日志文件，通常在顶部的菜单栏中显示网络应用）

这样，如果客户报告问题，我们可以使用版本号来跟踪他们是否正在使用最新版本以及特定版本中我们遇到了多少问题。

一切都与可追溯性有关！

我们使用Major.Minor.Build＃.YYMMDD [后缀]，因为我们通常只在特定的一天进行一次生产构建（但如果有多个，则使用ab / c / d后缀），而YYMMDD则为用户/客户/管理指示构建的年龄，而6.3.1389则没有。

主要产品数量随着重要产品功能（付费）的增加而增加。

次要数字随着修复/改进（免费更新）而增加。

建造总是在增加；并非所有的建造都可以交付，所以它不是线性发展。

版本号应具有足够的信息，可以避免冲突以及解决错误的发行类型问题中的错误，但不应传达不相关的其他信息。

例如，如果您使用日期，则客户可以告诉他们他们具有较旧的版本，而针对旧版本的补丁可能具有令人困惑的版本。

我个人喜欢语义版本控制：

• 版本是Major。Minor。Patch
• Patch 每次发布构建版本时都会递增。
• Minor 每次添加向后兼容功能时，它都会递增。
• Major 当新功能不向后兼容时增加。
• 当Major== 0时，您处于Alpha /预发行版本中。Major> = 1是您的公开发行版。
• 每次增加，较低的数字都会重置为0，因此

  1.5.3-> 1.5.4（错误修复）-> 1.6.0（次要功能）-> 2.0.0（重大更改）

              1.0.0
                |
              1.0.1
                |
（公开1.0版）1.0.2 -----
                | \
              2.0.0 1.1.0
                | |
              2.0.1 1.1.1（公共1.1）
                |
（公共2.0版）2.0.2 -----
                | \
              3.0.0 2.1.0
                         |
                       2.1.1（公共2.1）
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Z是我们的内部版本号。X.Y是公开版本号，对我们的客户有意义。当一个X.Y.Z版本公开时，将永远不会有一个X.Y.(Z+1)版本：公开版本始终是该系列的最后一个。

X 发行主要版本时递增。

Y 用于主要版本的维护分支，仅用于错误修复。

Z在内部使用，没有固定的含义。到现在为止，Z当我认为该应用程序具有一组非开发人员感兴趣的功能并且相对稳定时，我会创建一个新版本。这样，当有人问一个应用程序时，我可以演示该应用程序的“最新已知良好版本”的演示。在不久的将来，我计划Z在我们的Bugtracker中使用数字版本来命名功能的“目标”。

作为附带说明，我们使用maven（与release命令一起使用）增加版本号。因此，也有X.Y.Z-SNAPSHOT版本（表示X.Y.(Z-1)和之间的任何版本X.Y.Z）。