您何时更改主要/次要/补丁程序版本号？

可能重复：
您使用什么“版本命名约定”？

您是在发布前还是发布后立即更改主要/次要/补丁版本号？

示例：您刚刚向世界发布了1.0.0（真是！）。但是，等等，不要庆祝太多。1.1.0将在六周内发布！因此，您可以修复错误并重新构建。那叫什么建筑？1.1.0.0或1.0.0.xxxy（其中xxxy是1.0.0的内部版本号递增）？

请记住，您可能有100个要加入1.1.0的功能和错误。所以最好将其命名为1.0.0.xxxy，因为您距离1.1.0还差得远。但另一方面，另一个开发人员可能正在开发2.0.0，在这种情况下，您的构建可能会更好地命名为1.1.0.0和他的2.0.0.0，而不是分别是1.0.0.xxxy和1.0.0.xxxz。

发行软件后，应立即增加版本号。

为什么？

假设您正在遵循类似Semantic Versioning的方案，并且您在版本中具有内部版本号。因此，您可能有[Major]。[Minor]。[Patch]。[Build]。我将把这个版本称为[Major]。[Minor]。[Patch]部分。

在开发过程中，您将创建多个构建。每个构建都是下一个版本的开发快照。在开发和发行版本中使用相同的版本是有意义的。版本指示你的工作是什么释放走向。

如果您准备发布，并且该软件通过了所有测试，则您不会因为必须更新版本而希望重建并重新测试该软件。当最终发布时，您是在说“ build 1.1.0.23”此后将被称为“版本1.1.0”。

释放后增量模型对于分支也很有意义。假设您有一个主线开发分支，并且为发布创建了维护分支。创建发行分支后，开发分支将不再链接到该发行版的版本号。开发分支包含的代码是下一发行版的一部分，因此版本应反映出来。

我通常会尝试使用SemVer作为内部版本号。能够基于版本号的语义来了解某个发行版，这是很高兴的。

在开发过程中，我尝试立即更改版本号（如果可能）。有时很难知道更改是否会是一个重大更改（这将影响我的版本号），因此没有任何事情是一成不变的。

要解决您的特定示例：

• 在开发过程中，预发行版本将为1.0.1-alpha.1、1.0.1-alpha.2等。
• 该错误修复程序的最终版本为1.0.1。

话虽这么说，“面向公众”的产品版本号通常由市场营销部门设置，并且完全不同。这是我无法控制的，因此不必担心。

让我们假设答案中的ABCD。您何时增加每个组成部分？

它基本上由您的公司政策决定。我们的公司政策是：

• A-功能或界面上的重大更改（> 25％）。
• B-功能或界面上的微小更改或添加。
• C-破坏界面的微小更改。
• D-修复了不更改界面的构建。

在较大的项目/组织中，主要版本号和次要版本号由营销部门控制，并且通常出于营销原因而增加。在我的组织中，小组的目标是每年发布一个主要版本和一个次要版本。期望主要版本包含重要的新功能，并且具有相同主要版本号的所有版本的API之间都有二进制兼容性。但是，例如，市场营销部门可能会选择将主要版本更改降级为次要版本，因为没有兑现承诺的功能，反之亦然。

主要和次要内部版本号（abcd中的c和d）通常由开发控制。c是内部版本号，d用于特定版本或c版本的补丁。

在您的情况下，更改主要版本号和次要版本号与确保主要版本号和次要内部版本号没有太大关系。在我的组织中，作为源代码控制分支过程的一部分，我们更改了主要和次要的内部版本号。主分支通常包含最新版本，但是市场可能尚未决定该发行版的版本号。

我们尝试并遵循Eclipse示例。它在解释方面做得比我更好，但是对我们来说有效的是，它的工作方式如下：

当您发布1.0.0.0时，要更改的版本号取决于您要进行的更改的类型。

• 不会影响该API的发行版，考虑了使当前API以预期方式工作的后台错误修复程序，版本为1.0.1。
• 一个添加到API但未更改现有API的发行版，您可能已添加了一项新功能，该功能不会使当前客户端与新版本无法比拟。这也可以包括任何数量的上述修补程序。
• 发行版破坏了当前的API，删除了某些内容，并以破坏当前客户端可比性的方式更改了某些内容。这也可以具有上述修复的任何数量。

至于如何使用版本号的第四部分，我们用它来区分Nuget（我们用于.net的软件包管理解决方案）中的不同版本。这使我们避免每次需要更新未发布的软件时都必须清除缓存。

没有下一个版本。在那个分支上。

我们方案的理想化版本。

任何分支上的版本标识都是PRETTY_BRANCH_NAME-build，而PRETTY_BRANCH_NAME固定在分支创建时。

我们的分支方案（*）如下：

顶级分支，每个的PRETTY_BRANCH_NAME是一个代号，谈到该级别的版本号是没有意义的，可能有计划的方案，但是在发布之前会有所变化。

• 长期发展的TNG（下一代）分支。通常我们甚至没有它，并且它从来没有（发布）子分支。

• 进行当前开发的TCG（当前一代）分支。PRETTY_BRANCH_NAME是一个代号。

• TPG（上一代）分支。这里通常没有更多的发展，但是子支行中可能会有活动。

当主要版本的Beta版开始时，子分支由顶级分支（TCG的顶级分支）组成。PRETTY_BRANCH_NAME类似于“ 1.3.X”（X是字母，而不是数字，这意味着我们打算从此处提供1.3版本），此处将考虑来自beta的反馈，而下一个主要版本的工作已完成。 TCG分支。

理想情况下，发布应该是该分支上的快照，但是我们知道我们并不完美，通常需要在最后一刻进行更改，同时允许其他人继续为下一个次要版本工作。因此，将子分支用于最终的稳定化，用漂亮的名字作为正式版本号（当时甚至营销也不想更改它），例如“ 1.3.X”分支中的“ 1.3”，“ 1.3.1”，每个版本的最后一个版本是发行版。

如果我们具有第四级，则子子分支名称应为“ 1.3.0.X”，其中我们将具有子^ 3分支“ 1.3.0.0”和“ 1.3.0.1”。

（*）在发布级别。每个项目上可能都有项目子分支。

如果您正在销售软件，则每次销售/营销需要赚取更大的奖金时，您都会拥有一个新的主要版本：-)。

如果您有控制权，则：

1. 在以下情况下的主要版本：

   • 与以前的发行版有些不兼容，需要转换等，例如从Python 2到Python 3。

   • 有一大堆新功能。

2. 次要发行版，用于任何小的功能更改。

3. 修补程序版本，用于错误修复。