MAJOR.MINOR.BUILDNUMBER.REVISION中的内部版本号到底是什么

我对内部版本号的看法是，每当创建一个新的每晚内部版本时，都会生成一个新的BUILDNUMBER并将其分配给该内部版本。因此，对于我的7.0版本应用程序，夜间版本将为7.0.1、7.0.2等。是这样吗？那么在内部版本号之后REVISION的用途是什么？还是在每个夜间构建后增加REVISION部分？我在这里有点困惑...我们是否将每个每晚的建筑都称为BUILD？

此处提到了格式：AssemblyVersion-MSDN

我从未见过以这种形式写出来。在我工作的地方，我们使用MAJOR.MINOR.REVISION.BUILDNUMBER的形式，其中MAJOR是主要版本（通常是许多新功能或对UI或基础OS的更改），而MINOR是次要版本（可能是一些新功能）在以前的主要版本中，REVISION通常是对先前的次要版本（没有新功能）的修复，并且对于每个最新的修订版本，BUILDNUMBER都会增加。

例如，可能将修订发布到QA（质量控制），并且它们又回来了，并且需要更改。该错误将得到修复，并使用相同的REVISION号（但增加了BUILDNUMBER）释放回QA。

整个混乱源于MS用于“内部版本号”（尤其是“修订”）的不同语义。这些术语仅表示不同的意思。

大多数人（包括我自己在内）都使用语义版本编号方案，无论出于何种原因，无论何时您必须进行新的构建，都只会获得更高的BUILD号。对我们来说，此修补程序仅是另一个代码更改，并且每次运行CI时，BUILD部分都会自动增加。具有相同MAJ.MIN.REV的模块被认为是可互换的，并且BUILD会告诉您哪个是最新的。

但是，增加REVISION表示一个新的永久发行分支，这就是为什么我们将其放在BUILD之前。这种方法的缺点是，我们可能会得到以下事件序列：

• 提交编号4711：Alice添加了功能A
• CI生成版本1.2.3.100
• 提交编号4712：Bob修改了功能B
• 提交编号4713：Alice固定功能A（“修补程序”）
• CI生成版本1.2.3.101

如您所见，此修补程序不是下一个版本中唯一的更改，Bob的修改也成为该版本的一部分。如果您想稳定当前分支，可能会遇到麻烦，因为您永远无法确定Bob是否只是添加了一些bug。

MS使用这两个术语的方式有所不同。BUILD编号不会自动递增，而是可以视为一种发行分支，以冻结用于特定版本代码的代码。REVISION指示应用于该BUILD分支的其他“热”更改。因此，顺序如下：

• 提交编号4711：Alice向中继线/主控添加了功能A
• 卡尔创建了构建分支 1.2.100
• CI生成内部版本1.2.100.0
• 提交编号4712：Bob修改了主干/主控中的功能B
• 提交编号4713：1.2.100分支中的Alice固定功能A
• CI生成内部版本1.2.100.1

术语“修订”可以指

• 一个产品版本（这是大多数人如何使用它）
• 特定每日版本的修订版（MS就是这样做的）

这两个过程之间的主要区别在于，是否希望将修补程序应用于CI构建，以及因此需要在该过程中的哪个时间点进行分支。当您希望能够在所有测试成功之后随时选择特定的版本并将该版本完全升级到产品的下一个正式版本时，此方面就变得很重要。

在我们的案例中，CI工具会创建一个存储库标签，因此，在需要时，我们始终可以随时使用必要的信息。使用SVN，它变得更加简单，因为标记和分支的实现方式完全相同-标记不过是位于下方的分支/tags。

也可以看看

在TFS分支策略的FAQ部分中：

我应该在哪个分支修复P1（修补程序）票证？

• P1应该固定在最接近生产环境中运行的代码库的分支中。在这种情况下，P1应该固定在Prod分支中。通过在任何其他分支中应用此修补程序并将更改推广到生产中，您可能会在后续迭代中释放未完成或未经测试的代码。

• 现在您可能会争辩说直接对付Prod分支是否安全，请再考虑一遍，需要立即关注的P1不应成为系统中的基本问题。如果这是一个基本问题，则应将其添加到产品待办事项列表中，因为这可能需要与客户进行进一步的分析和讨论。

另一个很好的阅读是TFS分支指南

Microsoft在其MSDN文档中为Version该类描述了.NET版本号的每个组件的用途。这是相关的部分：

major.minor [.build [.revision]]

按照惯例，这些组件按以下方式使用：

专业：具有相同名称但主要版本不同的装配体不可互换。较高的版本号可能表示对产品的重大重写，其中不能假定向后兼容。

次要版本号：如果两个程序集上的名称和主要版本号相同，但是次要版本号不同，则表明进行了向后兼容的显着增强。较高的次要版本号可能表示产品的发行版或产品的完全向后兼容的新版本。

内部版本：内部版本号不同表示同一源的重新编译。处理器，平台或编译器更改时，可能会使用不同的内部版本号。

修订版：具有相同名称，主要和次要版本号但具有不同修订版的程序集可以完全互换。修订版本号可能会用在用于修复先前发布的程序集中的安全漏洞的版本中。

http://msdn.microsoft.com/zh-CN/library/system.version.aspx

我可以想象至少有几个不同的事情，内部版本号引用：

1. 已发布的源代码控制版本。例如，如果有版本＃12345的发行版，则可以通过将其作为内部版本号进行跟踪，并且如果对其进行了修补，则可以在该版本上进行修订，因为它不是增加主要或次要版本的新功能。并且必须记住内部版本号，以防有人想要再次运行该内部版本。

2. 持续集成服务器标识符。在这种情况下，CI服务器可以为它运行的每个内部版本编号，因此内部版本号是成功内部版本获得的版本，在这种情况下不需要修订部分。

可能还有其他我不认识的人，但是当涉及到基于代码的数字时，这些才是我所知道的。

内部版本号通常在每次内部版本时都会增加，因此它是唯一的。

为简单起见，每当遇到MAJOR或MINOR号时，都会重设内部版本号。

大多数持续集成引擎允许自动生成唯一的内部版本号。

该修订版可用于构建补丁。假设有2个团队在一个产品上工作。

团队1是主要的开发团队，并使用以下版本架构1.0.X.0（其中X递增）进行夜间构建。现在他们的版本为1.0.50.0，第2团队不时进行构建。假设他们从上周（即1.0.43.0）开始构建并开始使用它。当小组2在1.0.43.0中发现问题时，小组1前进至1.0.51.0。

现在，团队1将采用该版本（43），解决该问题，并为团队2提供版本1.0.43.1。该修复程序也可能在主版本中传播，因此更改将出现在1.0.52.0中。

希望这是清楚和有用的。

*当并非参与项目的每个人都使用相同的构建，并且您需要修补特定的构建时，修订版很有用。

让我说说我如何看待和使用它。

ProgramName版本major.minor.build.revision

major：对我来说，这是我目前正在从事的项目。在启动具有相同程序名称的新项目之前，该数字不会更改。这意味着我实际上将在编写一个相同性别的新程序（例如：访问v1-访问v-2-访问v-3 *所有相同的程序，但都被完全重写了）。

次要：这意味着我正在向当前发布的项目添加功能。例如，也许我增加了打印收据的能力或增加了导入图片的能力。基本上，我想立即添加其他功能，而不必等待下一个主要版本完成。

build：我用来表示已发布的major.minor版本中的很小变化。这可能是布局，配色方案等的变化。

修订版：这用于指示当前发布的major.minor.build中的错误修复-有时我没有在进行当前项目，因此会出现错误。此错误需要修复和发布。这仅表示我正在修正已经发布的内容以使其正常工作。如果我正在开发新版本，新添加版本或开始新的主要版本，我也会使用此版本。在我们等待下一个主要，次要或内部版本时，显然需要修补已发布的版本。

因此，以这种方式，完成的或停滞的项目仍然可以修复，并在下一个版本发布之前可用。

我希望这可以使人们更好地了解这种版本控制将如何（或应该）工作。对我来说，这是使用这种类型的版本控制时具有任何实际意义的唯一定义和实践。

我只看到过内部版本号作为发行ID中的最后一个数字。我不确定您将如何修订内部版本号。我想如果您更改了一些非构建资源（图标，DB脚本等），也许是可行的，但是我最近从事的大多数项目都具有所有这些受版本控制的东西，因此构建过程会在需要时进行选择制作安装程序/发行版。我喜欢带时间戳的内部版本号，尽管不像@David所描述的那样（我喜欢major.minor.revision.HHMM）。但是，在我工作的地方，我们只使用构建服务器生成的序列号。

像jkohlhepp一样，我们使用版本的第三部分在SubVersion中显示修订号，并在第四部分中显示来自持续集成服务器（对于我们来说是詹金斯）的内部版本号。这给我们带来了很多好处-由我们的CI服务器设置的版本号消除了手动步骤，否则可能会意外遗漏；可以很容易地检查出开发人员没有从他们的开发PC上发布过分的版本（这将导致这些数字为零）；并且它使我们能够将任何软件与生成软件的代码以及构建该软件的CI作业联系起来，仅需查看版本号即可，有时我们会发现这非常有用。

这就是您想要的。我倾向于在我的major.minor.build.revision中使用year.month.day.hhmm。如果我每分钟的产量不止一个，那是不对的。您可以只使用一个简单的增量，或者我已经看到了一些复杂的生成器。你想成为什么。他们需要做的就是制作它，以便您使用创建该输出的源代码，因此可以执行任何操作。

后两位数字是总内部编号

1.01.2.1234

内部版本号为2.1234，但是大多数人只会使用1234，因为这2部分不会经常更改。

我们的团队使用第三个数字（修订）作为Subversion存储库中的修订号。我们使用第四个数字（内部版本）作为来自TeamCity持续集成服务器的内部版本号，该服务器实际创建内部版本。在构建过程中，TeamCity用正确的#s创建一个新的AssemblyInfo文件。