最佳实践：软件版本控制

Question

是否有任何指导或标准的最佳实践如何在业余时间为您开发的软件进行版本设计以获得乐趣，但是有些人会使用它？我认为有必要对这样的软件进行版本化，以便您了解第一版所述的内容（例如，修复错误，支持等等）。

但是我从哪里开始版本控制？ 0.0.0？还是0.0？然后我如何增加数字？主要发布。小变化？并且不应该对版本控制系统的任何提交是另一个版本？或者仅适用于以高效方式使用的版本？

Answer 1

您应该从版本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（你修正了一些错误）。

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

Answer 2

我会使用x.y.z种版本

x - 主要发布
y - 次要释放
z - 内部版本号

Answer 3

我基本上遵循这种模式：

• 从0.1.0开始

• 当它准备就绪时我将代码分支到源代码库中，标记为0.1.0并创建0.1.0分支，头/主干变为0.2.0快照或类似的东西

• 我只将新功能添加到主干，但是后端修复了分支，并且我及时从中释放0.1.1,0.1.2，...

• 当产品被视为功能完整且没有重大缺点时，我声明版本1.0.0

从那时起

• - 每个人都可以决定何时增加主要版本...

Answer 4

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

X.Y.Z

其中：

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

示例：

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

Answer 5

我们使用a.b.c.d where

• a - major（在交付给客户时递增）
• b - 次要（在交付给客户时递增）
• c - 修订版（内部版本增加）
• d - 构建（通过巡航控制增加）

Answer 6

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

  

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

     

  
• 主要部分表示API中的破损
  
• 次要细分表示“外部可见”更改
  
• 服务部分表示错误修复和开发流程的更改
  
• 限定符段表示特定构建
  

Answer 7

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

这是非常有用的信息，因为第一次看起来会给出关于发布日期的印象。但我更喜欢x.y.z方案，因为我总是想知道产品在其生命周期中的确切点（Major.minor.release）

Answer 8

基本答案是“它取决于”。

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

如果您正在计划您的项目，那么我将为具有重大更改的版本增加修订版本，并为具有重大更改，错误修复或功能/功能的版本增加版本。如果您提供测试版或每晚构建类型版本，则扩展版本控制以包括每次发布时的构建和增量。

尽管如此，在一天结束时，这取决于你，它必须对你有意义。

Answer 9

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

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

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

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

Answer 10

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

版本号，标签，它就在那里。

Answer 11

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

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

一样

如果有任何新的CR或增强功能发生了一些细微的变化，则增加'b'。

如果代码中存在一些缺陷修复，则

增加'c'。

Answer 12

我开始在最低（非修补程序）segement版本。我不会将此段限制为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进行配置和运行就可以避免让您不必担心版本控制的意见方面，您只需说“使用工具”......因为开发过程中的每个人都是典型的所以符合。