最佳实践：软件版本控制 [关闭]答案

【问题标题】：Best Practice: Software Versioning [closed]最佳实践：软件版本控制 [关闭]
【发布时间】：2011-02-21 07:24:53
【问题描述】：

是否有任何指南或标准最佳实践如何为您在业余时间开发的软件进行版本控制，但仍然会被某些人使用？我认为有必要对此类软件进行版本化，以便您了解第一版正在谈论的内容（例如，用于错误修复、支持等）。

但是我从哪里开始版本控制呢？ 0.0.0？还是 0.0？然后如何增加数字？主要版本。微小的变化？对版本控制系统的任何提交都不应该是另一个版本吗？还是仅适用于以生产方式使用的版本？

【问题讨论】：

你的源代码控制工具是做什么的？您必须使用一个。你用的是哪一个？
我有点晚了...不过是stackoverflow.com/questions/615227/how-to-do-version-numbers的骗子
semver.org
@DaveGregory 对这个问题有一个非基于意见的答案。该链接semver.org 详细描述了版本控制语义。大多数 Google 项目（包括 Android）通常使用相同的方案。此外，在 Tom Preston-Werner 中，我们可以在这个主题上找到与任何人一样可信的声音。

【解决方案1】：

我从最低（非修补程序）段开始版本控制。我不将此段限制为 10。除非您正在跟踪构建，否则您只需要决定何时要应用增量。如果您有一个 QA 阶段，那么这可能是您对最低段应用增量的地方，然后在它通过 QA 并发布时应用下一个段。为主要行为/UI 更改保留最上面的部分。

如果您像我一样，您会将其混合使用各种方法，以便与您的软件发展步伐相匹配。

我认为最被接受的模式 a.b.c。或 a.b.c.d 特别是如果您有 QA/合规性。作为版本的常规部分，我有很多关于日期的问题，我放弃了它作为主流。

我不跟踪构建，所以我喜欢使用 a.b.c 模式，除非涉及修补程序。当我必须应用修补程序时，我将参数 d 应用为带时间的日期。我采用时间参数作为 d，因为当事情在生产中真正爆炸时，一天中总有几个潜力。我只在为生产修复分流时应用 d 段 (YYYYMMDDHHNN)。

我个人不会反对 va.b revc 的软件方案，其中 c 是 YYYYMMDDHHMM 或 YYYYMMDD。

说了这么多。如果您可以只使用snag a tool 来配置和运行它，那么您就不必为整理版本控制的意见方面而头疼，您只需说“使用该工具”……因为开发过程中的每个人通常都是 so 符合。

【讨论】：

【解决方案2】：

我将此规则用于我的应用程序：

x.y.z

地点：

x = 主版本号，1-~。
y = 特征编号，0-9。如果更改包含带有或不带有错误修复的新功能，请增加此数字。
z = 修补程序编号，0-~。如果更改仅包含错误修复，请增加此数字。

例子：

对于新应用程序，版本号以 1.0.0 开头。
如果新版本仅包含错误修复，请增加修补程序编号，使版本编号为 1.0.1。
如果新版本包含带有或不带有错误修复的新功能，请增加功能编号并将修补程序编号重置为零，以便版本编号为 1.1.0。如果功能编号达到 9，则增加主版本号并将功能和修补程序编号重置为零（2.0.0 等）

【讨论】：

我建议使用此方案，不要在“功能”/“修补程序”编号中滚动 9 -> 0，只需转到 10！ 10 个小更新如果是增量发布的，仍然是小更新，1.10.0 或 1.1.10 没有任何问题。
..并继续上升。如果在 v.2 之前你真的有 23 个特性要实现怎么办？然后对最后一个功能进行了 30 个错误修复？您将拥有版本 1.23.30。主要版本发布是具有一定里程碑意义的大抽象概念，无需随意遵守十进制计数规则。

【解决方案3】：

还有date versioning scheme，例如：YYYY.MM、YY.MM、YYYYMMDD

它的信息量很大，因为第一眼给人的印象是发布日期。但我更喜欢 x.y.z 方案，因为我总是想知道产品在其生命周期中的确切时间点（Major.minor.release）

【讨论】：

【解决方案4】：

A.B.C 方法的另一个示例是Eclipse Bundle Versioning。 Eclipse 包有第四部分：

在 Eclipse 中，版本号由四 (4) 个部分组成：3 个整数和一个分别名为 major.minor.service.qualifier 的字符串。每个片段捕获不同的意图：

主要部分表示 API 中的损坏

次要部分表示“外部可见”的更改

服务段表示错误修复和开发流的变化

限定符段表示特定的构建

【讨论】：

【解决方案5】：

我们遵循 a.b.c 方法，例如：

如果应用程序发生了一些重大变化，则增加“a”。就像我们将 .NET 1.1 应用程序升级到 .NET 3.5

如果有一些小的更改，例如任何新的 CR 或增强，则增加“b”。

如果代码中有一些缺陷修复，则增加“c”。

【讨论】：

【解决方案6】：

我们在哪里使用 a.b.c.d

a - 主要（交付给客户时增加）
b - 次要（交付给客户时增加）
c - 修订版（在内部版本中增加）
d - 构建（由巡航控制增加）

【讨论】：

【解决方案7】：

您知道您可以随时查看其他人在做什么。开源软件倾向于允许访问其存储库。例如，您可以将您的 SVN 浏览器指向 http://svn.doctrine-project.org 并查看实际项目使用的版本控制系统。

版本号、标签，应有尽有。

【讨论】：

【解决方案8】：

我基本上遵循这个模式：

从0.1.0开始
当它准备好后，我在源代码库中分支代码，标记 0.1.0 并创建 0.1.0 分支，head/trunk 变为 0.2.0-snapshot 或类似的东西
我只向主干添加新功能，但对分支进行了反向移植修复，并及时从中发布 0.1.1、0.1.2、...
当产品被认为功能完整且没有重大缺陷时，我宣布版本 1.0.0
从那时起 - 每个人都可以决定何时增加主要版本...

【讨论】：

如果我有超过 9 个功能，我可以写 x.20.0 吗？
@JemshitIskenderov 当然可以。

【解决方案9】：

正如马赫什所说：我会使用 x.y.z 类型的版本控制

x - 主要版本 y - 次要版本 z - 内部版本号

您可能想要添加日期时间，而不是 z。

当您有另一个版本时，您会增加次要版本。主要版本可能会保持 0 或 1，当您真正进行重大更改时您会更改它（通常是当您的软件处于与以前版本不向后兼容的地步，或者您更改了整个框架时）

【讨论】：

【解决方案10】：

你应该从版本 1 开始，除非你知道你“发布”的第一个版本在某种程度上是不完整的。

至于如何增加版本，这取决于您，但请使用主要、次要、内部版本编号作为指导。

没有必要将您提交到源代码管理的每个版本都作为另一个版本 - 您很快就会拥有一个非常大的版本号。当您向外界发布新版本时，您只需要增加版本号（以某种方式）。

因此，如果您从版本 1.0.0.0 到版本 2.0.0.0 进行重大更改（例如，您从 WinForms 更改为 WPF）。如果您进行较小的更改，则从 1.0.0.0 移动到 1.1.0.0（您添加了对 png 文件的支持）。如果您进行了微小的更改，则从 1.0.0.0 升级到 1.0.1.0（您修复了一些错误）。

如果您真的想了解详细信息，请使用最终编号作为每次签入/提交都会增加的内部版本号（但我认为这太过分了）。

【讨论】：

我对您的回答有疑问：如果我正在使用版本 1.0.0.0 并且我正在实施较小、较小或较大的更改，并且我还想使用内部版本号。我必须在哪个版本号上添加构建版本？想象一下，我正在从 1.0.0.0 迁移到 1.0.1.0。我必须将内部版本号放在哪个数字上？而且，在最终版本中，它的版本号（1.0.1.234）是否也会有内部版本号？
@VansFannel，我希望每次你碰到任何更高的数字时，内部版本号都会重置为 0。
@JeffreyKemp 是的，我想是的。但在工作中，我们使用一年中的日期，我不喜欢它。
呸，我也不喜欢这样:(
还应注意，主要版本中的更改通常不向后兼容。次要版本中的增量在主要版本中向后兼容。由于更改的大小，从硬编码的 MySQL 实现更改为通用实现可能是主要版本，但也可能被视为功能更改（次要），因为它保持向后兼容。

【解决方案11】：

基本答案是“视情况而定”。

您的版本控制目标是什么？许多人使用 version.revision.build 并且只向世界宣传 version.revision，因为那是发布版本而不是开发版本。如果你使用签入“版本”，那么你很快就会发现你的版本号变大了。

如果您正在计划您的项目，那么我会为具有较小更改的版本增加修订版，并为具有重大更改、错误修复或功能/特性的版本增加版本。如果您提供测试版或夜间构建类型版本，则扩展版本控制以包含构建并在每个版本中增加它。

不过，归根结底，这取决于您，并且必须对您有意义。

【讨论】：

【解决方案12】：

我会使用x.y.z 类型的版本控制

x - 主要版本
y - 次要版本
z - 内部版本号

【讨论】：

这类似于语义版本控制，请参阅semver.org