最佳实践：软件版本控制

Question

最佳实践：软件版本控制

versioning

211

有没有关于如何为你在业余时间开发的仅供娱乐但将被某些人使用的软件进行版本控制的指南或标准最佳实践？我认为有必要对这种软件进行版本控制，以便您知道正在谈论的版本（例如用于修复错误、支持等）。

但是我应该从哪里开始进行版本控制呢？0.0.0？还是0.0？然后我该如何增加这些数字？主要版本.次要更改？每次提交到版本控制系统都应该是另一个版本吗？还是只针对在生产环境中使用的版本？

- RoflcoptrException

2

你的源代码控制工具是干什么用的？你必须使用一个。你在使用哪个？ - S.Lott

3

我有点晚了...不过这个链接是 https://dev59.com/OHRB5IYBdhLWcg3weHHx 的复制。 - derivation

12

SemVer是一个版本控制系统，旨在通过清晰、简洁的规则来定义软件库版本号。每个版本号由三个数字组成：主版本号、次版本号和补丁号。这三个数字都是非负整数，版本号必须按照从左到右递增的方式进行指定。主版本号的变化表示向后不兼容的API修改，次版本号的变化表示向后兼容的功能性新增，而修订号的变化表示向后兼容的问题修复。此外，版本号还可以包括一个可选的预发布标识符和元数据。SemVer的规则是为了确保开发人员和用户能够轻松地理解软件库版本之间的区别，并确定何时需要更新其依赖关系。它已被广泛采用，包括npm、RubyGems和Docker等流行的软件包管理器和应用程序。 - Dave Gregory

1

@DaveGregory对这个问题给出了一个非意见性的答案。该链接semver.org详细描述了版本控制语义。大多数Google项目，包括Android，都使用相同的方案。此外，在Tom Preston-Werner身上，我们可以找到任何关于这个主题的可信声音。 - Rahul Murmuria

12个回答

63

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

x - 主要版本号
y - 次要版本号
z - 构建编号

- Mahesh Velaga

2

这类似于语义化版本控制，请参见semver.org。 - Carlos Morales

42

我基本上遵循以下模式：

从0.1.0版本开始
准备好后，我会在源代码库中分支代码，标记为0.1.0并创建0.1.0分支，主干/头变成0.2.0-snapshot或类似的版本。
我仅将新功能添加到主干，但将修复内容嵌入到分支中，并在一段时间后从分支发布0.1.1，0.1.2等版本。
当产品被认为具有完整功能且没有重大缺陷时，我宣布版本1.0.0。
从那时起-每个人都可以决定何时增加主要版本号......

- Bozhidar Batsov

如果我有超过9个特征，我可以写x.20.0吗？ - Jemshit Iskenderov

@JemshitIskenderov 当然可以。 - Pavel S.

35

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

x.y.z

其中：

x = 主版本号，1-~。
y = 功能号，0-9。如果更改包含新功能（带或不带错误修复），请增加此数字。
z = 热修复号，0-~。如果更改仅包含错误修复，请增加此数字。

示例：

对于新应用程序，版本号从1.0.0开始。
如果新版本只包含错误修复，请增加热修复号，这样版本号将为1.0.1。
如果新版本包含新的功能（带或不带错误修复），请增加功能号并将热修复号重置为零，这样版本号将为1.1.0。如果功能号达到9，请增加主版本号并将功能和热修复号重置为零（2.0.0等）

- Lorensius W. L. T

36

我建议在“特性”/“热修复”编号中不要将9滚动到0，而是直接使用10！如果逐步发布，则即使有10个较小的更新，它们仍然是较小的更新，1.10.0或1.1.10也没有问题。 - ttarik

4

继续向上前进。假设你确实有23个功能需要在v.2之前实现，然后针对该最后一个功能有30个bug修复？那么你将会拥有版本1.23.30。主要版本发布是具有特定里程碑的大型抽象概念，没有必要死板地遵循十进制计数规则。 - brianclements

11

我们使用a.b.c.d来表示版本号，其中：

a - 主版本号（交付给客户端时递增）
b - 次版本号（交付给客户端时递增）
c - 修订版本号（内部发布时递增）
d - 构建版本号（由Cruise Control自动递增）

- Naeem Sarfraz

5

另一个使用 A.B.C 方法的例子是 Eclipse Bundle Versioning。Eclipse bundles有四个部分：

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

主要部分表示API的破坏

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

服务部分表示bug修复和开发流的更改

限定符部分表示特定的构建

- cuh

5

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

这种方案非常信息丰富，因为一眼就能给人留下发布日期的印象。但我更喜欢x.y.z方案，因为我总是想知道产品在其生命周期中的确切点位（Major.minor.release）。

- athspk

2

基本答案是“取决于情况”。

你的版本控制目标是什么？许多人使用version.revision.build，并且只向外界发布version.revision，因为那是一个发布版本而不是开发版本。如果你使用check-in 'version'，那么你很快就会发现你的版本号变得很大。

如果你正在计划你的项目，那么我建议你在具有次要更改的发布中增加revision，在具有重大更改、错误修复或功能/特性的发布中增加version。如果你提供beta或每夜构建类型的发布，则将版本控制扩展到包括构建，并随着每个发布增加版本号。

但最终，这取决于你自己，必须对你有意义。

- Lazarus

2

正如Mahesh所说：我会使用x.y.z这种版本号命名方式。

x - 主要版本 y - 次要版本 z - 构建编号

你可能想要添加日期时间，也许可以代替z。

当你有另一个发行版时，你会增加次要版本。主要版本通常会保持为0或1，只有在真正进行重大更改（通常是在软件不再向后兼容以前的版本或更改整个框架时）时才会更改它。

- Len

2

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

版本号、标签，一应俱全。

- Manos Dilaverakis

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- ChrisF · Accepted Answer

除非您知道第一个版本“发布”存在某种不完整的情况，否则应从版本1开始。

至于如何递增版本，这取决于您自己，但可以使用主要、次要、生成编号作为指南。

没有必要将提交到源代码控制的每个版本都视为另一个版本-否则您很快就会有一个非常大的版本号。只有在向外部世界发布新版本时才需要以某种方式递增版本号。

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

如果您真的想要详细了解，可以使用最后一个数字作为生成号码，每次检入/提交时都会递增（但我认为这做得太过头了）。