versioning - 您推荐什么版本编号方案？

Question

我的问题是，哪种版本命名方案应该用于什么类型的项目。

非常常见的是major.minor.fix，但即使这样也可能导致4 个数字（即Firefox 2.0.0.16）。有些有一个模型，奇数表示开发人员版本，偶数表示稳定版本。各种添加都可以进入组合，如 -dev3、-rc1、SP2 等。

有理由更喜欢一种方案而不是另一种方案，不同类型的项目（即开源与闭源）是否应该有不同的版本命名方案？

score 30 · Accepted Answer

对此有两个很好的答案（加上很多个人喜好；参见 gizmo 对宗教战争的评论）。

对于公共应用程序，该标准Major.Minor.Revision.Build最适用于 IMO - 公共用户可以轻松地判断他们拥有的程序版本，以及在某种程度上，他们的版本已经过时了。

对于内部应用程序，用户从不要求应用程序，部署由 IT 处理，用户将致电服务台，我发现Year.Month.Day.Build在很多情况下工作得更好。因此，可以对该版本号进行解码，以便为帮助台提供比公共版本号方案更有用的信息。

然而，在一天结束的时候，我会提出一个高于一切的建议——使用一个你可以保持一致的系统。如果有一个系统可以设置/编写编译器以每次自动使用，请使用.

可能发生的最糟糕的事情是您发布的二进制文件与以前的版本号相同 - 我最近一直在处理自动网络错误报告（其他人的应用程序），并得出的结论是 Year.Month.Day。核心转储中显示的构建版本号甚至与应用程序本身没有远程更新（应用程序本身使用带有实数的启动屏幕 - 当然，这不是从二进制文件中提取的，就像人们可能假设的那样）。结果是我无法知道故障转储是来自 2 年前的二进制文件（版本号表示的内容）还是 2 个月前的二进制文件，因此无法获得正确的源代码（也没有源代码控制！ )

score 28 · Accepted Answer

我是语义版本控制的忠实粉丝

正如许多其他人所评论的那样，这使用了 XYZ 格式，并给出了很好的理由。

score 27 · Accepted Answer

这是我们在公司中使用的：Major。未成年人。补丁版本。内部版本号。

重大变化涉及一个完整的发布周期，包括营销参与等。这个数字由研发之外的力量控制（例如，在我工作的一个地方，营销决定我们的下一个版本将是“11” - 以匹配竞争对手。我们当时是第 2 版:))。

将新功能或主要行为更改添加到产品时会更改次要更改。

每次正式向版本添加补丁时，补丁版本都会增加一个，通常仅包括错误修复。

当为客户发布特殊版本时使用构建版本，通常带有特定于他的错误修复。通常，该修复将汇总到下一个补丁或次要版本（并且产品管理通常在我们的跟踪系统中将错误标记为“将为补丁 3 发布”）。

score 25 · Accepted Answer

我们研发部门使用1.0.0.0.0.000：MAJOR.minor.patch.audience.critical_situation.build

请，请，不要那样做。

score 18 · Accepted Answer

这种问题更多是关于宗教战争而不是客观方面。对于编号方案或其他方案，总是有很多优点和缺点。人们可以（或应该）给您的只是他们使用的方案以及他们选择它的原因。

在我这边，我使用 XYZ 方案，所有这些都是数字，其中：

X表示公共 API 中引入向后不兼容的更改
Y表示添加了一些功能
Z表示修复（要么修复错误，要么在不影响功能的情况下更改内部结构）

最后，如果我想在正式发布之前从用户那里得到一些反馈，我会使用“Beta N”后缀。没有“RC”后缀，因为没有人是完美的，总会有错误 ;-)

score 9 · Accepted Answer

我们更喜欢major. minor. milestone. revision-build方案，其中：

major：显着的架构变化或功能的重要进步时的增量。
minor：不需要架构更改的小更改和新功能。
milestone：表示代码的稳定性和成熟度：
- 0 用于开发/pre-alpha
- 1 代表阿尔法
- 2 测试版
- 3 用于发布候选 (RC)
- 4 用于最终/生产版本
revision：表示版本、补丁或错误修复编号。
build：对应用程序的特定构建或版本的唯一引用。内部版本号是一个连续的整数，通常在每次构建时递增。

例子：

1.4.2.0-798: 版本的第一个 beta 版本1.4，由内部版本号创建798。
1.8.3.4-970: 1.8-RC4，由内部版本号创建970。
1.9.4.0-986: 版本的第一个生产版本1.9，由内部版本号创建986。
1.9.4.2-990: 版本的第二个错误修正版本1.9，由内部版本号创建990。

由于生产版本始终具有4版本字符串的第 3 位，因此可能会删除该数字以用于生产版本。

score 6 · Accepted Answer

我个人更喜欢 MAJOR.MINOR.BUGFIX-SUFFIX，其中 SUFFIXdev用于开发版本（版本控制检出），rc1/rc2用于发布候选版本，没有后缀用于发布版本。

如果您有用于开发检查的后缀，甚至可能带有修订号，则无需将它们设置为偶数/奇数以将它们分开。

score 4 · Accepted Answer

对于库，版本号告诉您两个版本之间的兼容性级别，以及升级的难度。

错误修复版本需要保留二进制、源代码和序列化兼容性。

次要版本对不同的项目意味着不同的东西，但通常它们不需要保持源代码兼容性。

主要版本号可以打破所有三种形式。

我在这里写了更多关于基本原理的文章。

score 4 · Accepted Answer

随着敏捷软件开发实践和 SaaS 应用程序的出现，主要版本与次要版本的概念已经消失——版本非常频繁地定期发布——因此依赖于这种区别的版本编号方案对我不再有用。

我的公司使用一种编号方案，该方案采用发布开始年份的最后 2 位数字，后跟该年份的发布编号。

因此，2012 年开始的第四个版本是 12.4。

如有必要，您可以在其后包含一个“错误修复”版本号，但理想情况下，您发布的频率足够高，以至于这些通常不需要 - 所以“12.4.2”。

这是一个非常简单的方案，并没有给我们带来我之前使用过的其他版本编号方案的任何问题。

score 1 · Accepted Answer

封闭和开源版本号政策之间的差异也可能来自商业方面，例如主要版本可以反映发布年份。

score 1 · Accepted Answer

我们以前在这里做的是major.minor.platform.fix。

主要：当此版本中保存的文件不再与以前的版本兼容时，我们会增加此数字。
示例：3.0.0.0 版本中保存的文件将与 2.5.0.0 版本不兼容。

次要：添加新功能时，我们会增加此数字。用户应该看到此功能。不是开发人员的隐藏功能。当major 增加时，这个数字被重置为0。

平台：这是我们用于开发的平台。
示例：1 代表 .net 框架版本 3.5。

修复：当这个新版本只包含错误修复时，我们会增加这个数字。当major 或minor 递增时，此数字重置为0。

score 1 · Accepted Answer

1

简单地

Major.Minor.Revision.Build

于 2008-11-20T13:39:38.747 回答

versioning - 您推荐什么版本编号方案？

12 回答 12

例子：

Related

Reference