如何处理版本号？

“版本号”是内部版本控制系统的问题。发布号是另一回事(并且应该保持不同)。

坚持使用简单的 MAJOR.MINOR 发布系统(如1.27版本) ，其中 MAJOR 是兼容级别(2.x 版本与1.x 版本不兼容，或者至少与1.x 版本有很大不同) ，MINOR 是你的 bug 修复版本或次要增强版本。只要遵循 X.Y 格式，您还可以使用其他系统，如 YAR.MONTH (2009.12)或 YAR.RELEASE (2009.3)。但实际上，你最好还是坚持少校。除非你有一个很好的理由不这样做。

绝对不要使用任何不符合 X.Y 格式的东西，因为它会使发行版、公告网站等很难与你合作，而这本身就会严重影响你的项目的受欢迎程度。

在您的(最好是分布式的)版本控制系统中使用分支和标记来分别标记与 MAJORS 和 MINORS 相关的特定内部版本号。

是的，1.0应该是稳定的。所有版本都应该是稳定的，除非它们被标记为 alpha、 beta 或 RC。使用阿尔法表示已知的破碎和不完整。已知破碎的贝塔。RCs 的意思是“尝试一下; 你可能会发现我们遗漏的东西”。任何没有其中之一的东西都应该(理想情况下，当然)进行测试，知道良好，有一个最新的手册，等等。

我们已经花费了太多的时间来决定何时增加主版本。有些商店很少这样做，所以你会有像1.25.3这样的发行版，其他商店会一直这样做，给你15.0版本

我对此感到厌烦，并说服每个人主要发行号码只是一年，未成年人只是一个连续发行在一年内。用户似乎很喜欢它，想出下一个版本号也是显而易见的。

年，释放，构建

• 年 = 本年
• 公开发布 = 公开发布的次序 # 新功能-重置为1每 年
• Build = bug 增量 修复程序和内部版本

剪辑

这是一个不断增强的内部应用程序

这可能不适用于商业应用程序，因为出于营销和财务目的，在一年中的不同时间发布主要应用程序是很重要的。

这个问题之所以存在，是因为我们没有一个统一的组态管理。

我喜欢这样做的版本号只是增量整数从1。我不想要一个多部分的版本号，我将不得不解释或文件。我不想使用 SVN 转速，因为这也需要一些解释。

您需要在 SVN 之上使用一些发布脚本来实现这一点

我们使用一个简单的 Major. minor.julian _ date 语法。

何处;

• Major-第一个版本是1，然后当我们引入重要的新特性或者变化时，它们不能向后兼容增加这个数字。
• 次要版本-主要里程碑版本。对于由生产推动的每个构建，这个数字都会增加。
• Julian _ date-构建的 朱利安 · 戴被推送到 QA。

在1/15推送到 QA 的第一个版本的示例是-> 1.0.015
第一个被推到3/4生产环境的版本的例子是-> 1.1.063

它并不完美，但是在我们几乎每天向 QA 推送构建时非常方便。

这里有些好消息:

何时更改文件/程序集版本

首先，文件版本和程序集版本不必相互重合。我建议文件版本随着每次构建而变化。但是，不要为了能够区分同一文件的两个版本之间的差异而在每次构建时更改汇编版本; 应该使用文件版本。决定何时更改程序集版本需要对要考虑的生成类型进行一些讨论: 传送和不传送。

非船舶建造 一般来说，我建议在发布版本之间保持非发布程序集版本相同。这避免了由于版本不匹配而导致的强名称程序集加载问题。有些人喜欢使用发布者策略为每个版本重定向新的程序集版本。但是，我建议不要对非发货构建使用这种方法: 它并不能避免所有的加载问题。例如，如果合作伙伴复制了您的应用程序，他们可能不知道安装发布者策略。然后，您的应用程序将为他们破解，即使它在您的机器上工作得很好。

但是，如果在同一台机器上不同的应用程序需要绑定到不同版本的程序集，我建议给这些构建不同的程序集版本，这样就可以在不使用 LoadFrom/等的情况下为每个应用程序使用正确的版本。

航运业 至于为了发布构建而更改该版本是否是一个好主意，这取决于您希望绑定如何为最终用户工作。您希望这些构建是并排的还是就地的？这两个版本之间有很多变化吗？他们要打击一些顾客吗？您是否关心它会破坏它们(或者您想强制用户使用您的重要更新) ？如果是，则应考虑递增程序集版本。但是，再次考虑这样做太多次可能会使用户的磁盘充满过时的程序集。

更改程序集版本时 为了将硬编码版本更改为新版本，我建议在头文件中为版本设置一个变量，并用该变量替换源中的硬编码。然后，在构建过程中运行一个预处理器以放入正确的版本。我建议在发货后立即更改版本，而不是在发货前更改，这样就有更多的时间来捕捉因更改而产生的 bug。

版本方案: [大调]。[小调]。[德维尔][标记]
[ main ] : 如果你在开发中有一个巨大的变化，就会增加。
[ small ] : 如果在开发中有小的变化，则增加。
[ devrel ] : 如果你修复了一个错误，那么增量。如果是大 + + 或小 + + ，那么重置为零。
[ mark ] : a，b 或 rc: a 是 alpha 版本，b 是 beta 版本，rc 是候选版本。注意，像1.3.57 a 或1.3.57 b 或1.3.57 rc 这样的版本是在1.3.57版本之前的。从0.0开始。

基于我在复杂企业平台级依赖管理和发布版本控制方面的经验，我推荐一种我喜欢称为 半语义版本控制的方法。

它基本上是建立在 语义版本2.0的基础上的，但并不那么严格。

半语义版本部分:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

主要版本分段格式:

市场营销，少校，少校，补丁

每个段都应该允许使用字母数字，但是对于逻辑增量更改，建议使用纯数字。

与 SemVer 类似，我建议使用 主要、次要和补丁组件来表示反向兼容性层，但也建议使用 市场营销部分。这使得产品所有者、特性史诗/组和业务关注点可以独立于技术兼容性关注点而突破主要组件。

与其他答案不同的是，我不建议在主段后面追加一个 Build 编号。相反，在“ +”后面添加一个 释放后环节(例如: 1.1.0.0 + build. 42)。SemVer 称之为构建元数据，但我认为发布后部分更清晰。这个段非常适合声明后缀数据与主 发布环节中的兼容性信息无关。您的持续集成构建可以给出之前的版本号，并附加一个在每个主版本之后重置的增量构建号(比如: 1.1.0.0-> 1.1.0.0 + build. 1-> 1.1.0.0 + build. 2-> 1.1.0.1)。有些人喜欢将 svn 修订号放在这里，或者将 git 提交 sha 放在这里，以便于绑定到代码存储库。另一种选择是使用发布后段来修补和补丁，因此可能值得考虑为此添加一个新的主要发布组件。当补丁组件增加时，它总是可以被删除，因为版本实际上是左对齐和排序的。

除了发布和发布后的部分，人们通常希望使用 预发行部分来表示几乎稳定的预发布版本，如 alpha、 beta 和发布候选版本。SemVer 方法可以很好地解决这个问题，但是我建议将数值组件从 alpha-numeric 分类器(例如: 1.2.0.0 + alpha. 2或1.2.0.0 + RC. 2)中分离出来。通常你会在添加发布后段的同时删除发布前段，然后在下一次删除主段时删除预发布段(比如: 1.0.1.2-> 1.2.0.0-RC 1-> 1.2.0.0)。预发布片段被添加来表明发布版本即将到来，通常只是一组固定的特性，用于更深入的测试和共享，不会随着更多的提交而随时变化。

以涵盖几乎所有用例的方式对所有这些进行语义定义的好处在于，您可以以标准方式解析、排序、比较和增量它们。当使用 CI 系统来处理复杂的应用程序时，这一点尤其重要，因为这些应用程序包含许多独立版本的小组件(比如微服务) ，每个组件都有自己的托管依赖关系。