最佳实践：软件版本控制

211

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

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

versioning 
— RoflcoptrException
source
2
您的源代码控制工具有什么作用？您必须使用一个。您正在使用哪一个？
— S.Lott 2010年
3
— 推导
12
— Dave Gregory
1
@DaveGregory对问题有一个非基于观点的答案。该链接semver.org详细描述了版本控制语义。大多数Google项目（包括Android）通常使用相同的方案。此外，在汤姆·普雷斯顿-维尔纳中，我们可以找到与此主题相关的可靠声音。
— Rahul Murmuria '16

Answers:

125

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

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

— ChrisF
source
我对您的回答有一个疑问：如果我正在使用1.0.0.0版，并且正在实施较小，较小或较大的更改，并且我也想使用内部版本号。我必须在哪个版本号上添加构建版本？想象一下，我正在从1.0.0.0升级到1.0.1.0。我必须在哪个编号上输入内部版本号？并且，在最终版本中，它的版本号（1.0.1.234）上还会有内部版本号吗？
— VansFannel
@VansFannel，我希望每次您碰到任何更高的数字时，内部版本号都会重置为0。
— 杰弗里·肯普
@JeffreyKemp是的，我是这样认为的。但是在工作中，我们使用年份的天数，但我不喜欢它。
— VansFannel
uck，我也不会喜欢:(
— Jeffrey Kemp
2
还应注意，主要版本中的更改通常不向后兼容。次要版本中的增量在主版本中向后兼容。由于更改的大小，从硬编码的MySQL实现更改为通用实现可能是主要版本，但由于仍保持向后兼容，因此也可以视为功能更改（次要）。
— DHW
42

我基本上遵循这种模式：

  • 从0.1.0开始

  • 准备好后，我在源存储库中分支代码，标记0.1.0并创建0.1.0分支，head / trunk变为0.2.0快照或类似内容

  • 我仅向中继添加了新功能，但向分支修复了反向移植，并及时将其从0.1.1、0.1.2，...发布了。

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

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

— 博吉达尔·巴佐夫（Bozhidar Batsov）
source
如果我具有9个以上的功能，可以写x.20.0怎么办？
— 杰姆西特·伊斯肯德罗夫
@JemshitIskenderov当然可以。
— 帕维尔S.16年
35

我在我的应用程序中使用以下规则：

y

哪里：

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

例：

  • 对于新应用程序，版本号以1.0.0开头。
  • 如果新版本仅包含错误修复，请增加此修补程序编号，以便版本号为1.0.1。
  • 如果新版本包含具有或没有错误修复的新功能，请增加功能编号并将修补程序编号重置为零，以便版本号为1.1.0。如果功能部件号达到9，请增加主版本号并将功能部件和修补程序号重置为零（2.0.0等）
— 洛伦修斯WL T
source
36
我建议使用此方案，而不要在“功能” /“修补程序”数字中将9-> 0翻滚，只需转到10！如果以增量方式发布10个次要更新，它们仍然是次要更新，而1.10.0或1.1.10没什么错。
— ttarik 2012年
4
..并继续上升。如果在v.2之前确实要实现23个功能怎么办？然后是最后一个功能的30个错误修正？您将拥有版本1.23.30。主版本发布是具有某些里程碑的大型抽象概念，无需任意遵守十进制计数规则。
— 贿赂2015年
11

我们在这里使用abcd

  • -专业（交付给客户时增加）
  • b-未成年人（交付给客户时有所增加）
  • c-修订（在内部版本中增加）
  • d-构建（由巡航控制系统增加）
— 奈姆·萨弗拉兹（Naeem Sarfraz）
source
5

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

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

  • 主要部分表示API损坏
  • 次要部分表示“外部可见”更改
  • 服务部分指示错误修复和开发流程的更改
  • 限定词段表示特定的构建
— h
source
5

也有日期的版本方案，如：YYYY.MM，YY.MM，YYYYMMDD

内容丰富，因为初看起来给人有关发行日期的印象。但是我更喜欢xyz方案，因为我一直想知道产品生命周期中的确切时间（Major.minor.release）

— athspk
source
2

基本答案是“取决于”。

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

如果您正在计划项目，那么我将为具有较小更改的发行版增加修订版，为具有重大更改，错误修复或功能/功能的发行版增加版本。如果要提供Beta版或每夜构建类型发行版，请扩展版本控制以包括构建并在每个发行版中增加该版本。

尽管如此，归根结底还是取决于您，这对您来说很有意义。

— 拉撒路
source
2

正如Mahesh所说：我将使用xyz类型的版本控制

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

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

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

— 朗兹爵士
source
2

我们遵循abc方法，例如：

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

如果有一些小变化，例如任何新的CR或实施了增强功能，则显示“ b”。

如果代码中有一些缺陷修复，则显示'c'。

— 阿曼迪普·基拉（Amandeep Kirar）
source
0

我从最低（非修补程序）段开始进行版本控制。我不会将此细分限制为10。除非您正在跟踪构建，否则只需确定何时要应用增量。如果您有质量检查阶段，则可能是在最低部分上增加了一个增量，然后在下一个部分通过质量检查并被释放时向上增加了一个部分。将主要行为/ UI更改留在最上面的细分。

如果您像我一样，可以将其混合使用，以适应软件开发的进度。

我认为最受欢迎的模式是abc或abcd，尤其是如果您有质量保证/合规性的话。我在版本中经常遇到一些问题，因此放弃了主流版本。

我不跟踪构建，因此除非涉及修补程序，否则我喜欢使用abc模式。当我必须应用修补程序时，我将参数d用作带时间的日期。我将时间参数设为d，是因为在一天中实际发生生产爆炸时，总会有数个潜力。当我为生产修订而分歧时，我仅应用d段（YYYYMMDDHHNN）。

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

所有这些。如果您只能使用某个工具来配置和运行该工具，则可以避免麻烦，不必整理版本管理的观点，而您只能说“使用该工具”……因为开发过程中的每个人通常都非常合规。

— 卢海顿
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.