我在线分发软件，并且总是想知道是否有更好的方法来更好地定义版本号。
让我们在答案中假设 ABCD。你什么时候增加每个组件？
您是否使用任何其他版本号技巧，例如 D mod 2 == 1 意味着它仅是内部版本？
您是否有带有自己版本号的 beta 版本，或者您是否有每个版本号的 beta 版本？
Brian R. Bondy
问问题
12209 次
15 回答
29
我开始喜欢某些应用程序（例如 Perforce）使用的 Year.Release[.Build] 约定。基本上它只是说明你发布的年份，以及那一年的顺序。所以 2008.1 将是第一个版本，如果您在一个月或三个月后发布另一个版本，它将转到 2008.2。
这种方案的优点是没有隐含的发布“数量”，您可以在其中争论某个功能是否足够重要以保证主要版本的增加。
一个可选的附加功能是标记内部版本号，但这往往仅用于内部目的（例如添加到 EXE/DLL 以便您可以检查文件并确保存在正确的版本）。
于 2008-09-25T17:27:48.263 回答
8
在我看来，几乎任何版本号方案都可以或多或少地正常工作。我工作的系统使用版本号，例如 11.50.UC3，其中 U 表示 32 位 Unix，而 C3 是次要修订（修订包）号；其他字母用于其他平台类型。（我不推荐这个方案，但它有效。）
到目前为止，有一些黄金法则尚未阐明，但隐含在人们所讨论的内容中。
- 不要两次发布相同的版本 - 一旦 1.0.0 版本发布给任何人，就永远无法重新发布。
- 发布数量应该单调增加。也就是说，版本 1.0.1 或 1.1.0 或 2.0.0 中的代码应始终晚于版本 1.0.0、1.0.9 或 1.4.3（分别）。
现在，在实践中，人们确实必须在有新版本可用时发布旧版本的修复程序——参见 GCC，例如：
- GCC 3.4.6 在 4.0.0、4.1.0（和 AFAICR 4.2.0）之后发布，但它继续 GCC 3.4.x 的功能，而不是添加添加到 GCC 4.x 的额外功能。
因此，您必须仔细构建您的版本编号方案。
我坚信的另一点：
- 发布版本号与CM（VCS）系统版本号无关，小程序除外。任何具有多个主要源文件的严肃软件都将具有与任何单个文件的版本无关的版本号。
使用 SVN，您可以使用 SVN 版本号 - 但可能不会，因为它的变化太不可预测。
对于我使用的东西，版本号纯粹是政治决定。
顺便说一句，我知道一些软件从 1.00 版到 9.53 版都经过了发布，但后来又变成了 2.80 版。这是一个严重的错误——由营销决定。诚然，该软件的 4.x 版本已经过时，因此不会立即引起混淆，但该软件的 5.x 版本仍在使用和销售中，并且修订版已经达到 3.50。当不可避免的冲突发生时，我非常担心我的代码必须与 5.x（旧样式）和 5.x（新样式）一起使用。我想我必须希望他们在更改为 5.x 时会犹豫不决，直到旧的 5.x 真的死了——但我并不乐观。我还使用人工版本号，例如 9.60，来表示 3.50 的代码，这样我就可以进行理智的if VERSION > 900测试，而不必这样做：if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400)，其中我用 900 表示版本 9.00。然后是版本 3.00.xC3 中引入的重大更改——我的方案无法检测到次要版本级别的更改......抱怨......抱怨......
注意：Eric Raymond 提供了软件发布实践 HOWTO，包括关于命名（编号）发布的（链接）部分。
于 2008-09-28T04:50:45.070 回答
7
我通常使用 D 作为构建计数器（由编译器自动递增）每次构建发布到“公共”时我都会递增 C（不是每个构建都发布） A 和 B 用作主要/次要版本号并手动更改。
于 2008-09-25T17:04:49.193 回答
5
我认为有两种方法可以回答这个问题，它们并不完全是互补的。
- 技术：根据技术任务增加版本。示例：D 是内部版本号，C 是迭代，B 是次要版本，A 是主要版本。定义次要版本和主要版本确实是主观的，但可能与底层架构的更改等相关的事情。
- 营销：根据向客户提供的“新”或“有用”功能的数量增加版本。您还可以将版本号绑定到更新策略...对 A 的更改需要用户购买升级许可证，而其他更改则不需要。
我认为，最重要的是找到适合您和您的客户的模型。我见过一些情况，其中偶数版本是公开版本，而奇数版本被认为是 beta 或 dev 版本。我见过一些忽略 C 和 D 的产品。
然后是来自 Micrsoft 的示例，其中对 .Net Framework 版本号的唯一合理解释是涉及营销。
于 2008-09-25T17:09:49.070 回答
4
我们的政策：
- A - 功能或界面的重大 (> 25%) 更改或添加。
- B - 功能或界面的小改动或添加。
- C - 破坏界面的小改动。
- D - 修复不更改界面的构建。
于 2008-09-25T17:02:28.527 回答
2
人们往往想让这比它真正需要的更难。如果您的产品只有一个长期存在的分支，只需按其内部版本号命名后续版本。如果您有某种“小错误修复是免费的，但您必须为主要的新版本付费”，那么使用 1.0、1.1 ... 1.n、2.0、2.1...等。
如果您无法立即弄清楚示例中的 A、B、C 和 D 是什么，那么您显然不需要它们。
于 2008-09-25T17:03:04.203 回答
2
我对版本号的唯一用途是让客户可以告诉我他们使用的是 2.5.1.0 版或其他版本。
我唯一的规则是尽量减少报告该数字时的错误： 所有四个数字都只能是 1 位数字。
1.1.2.3
可以，但是
1.0.1.23
不是。客户可能会将这两个数字（至少口头上）报告为“一一二三”。
自动递增内部版本号通常会导致版本号，例如
1.0.1.12537
这也无济于事。
于 2008-09-25T17:17:37.213 回答
2
一个好的非技术方案只使用这种格式的构建日期：
YYYY.MM.DD.BuildNumber
其中 BuildNumber 是一个连续的数字（更改列表）或每天从 1 开始。
示例：2008.03.24.1 或 2008.03.24.14503
这主要用于内部发布，如果您不经常发布每月一次，公开发布会看到打印为 2008.03 的版本。维护版本被标记为 2008.03a 2008.03b 等等。他们应该很少超过“c”，但如果它是一个很好的指标，你需要更好的 QA 和/或测试程序。
用户常见的版本字段应以友好的“2008 年 3 月”格式打印，在“关于”对话框或日志文件中保留更多技术信息。
最大的缺点：只是在另一天编译相同的代码可能会更改版本号。但是您可以通过使用版本控制更改列表作为最后一个数字并检查以确定是否也需要更改日期来避免这种情况。
于 2008-09-25T21:16:46.107 回答
2
在 github 世界中，遵循 Tom Preston-Werner 的版本号“semver”规范变得很流行。
给定版本号 MAJOR.MINOR.PATCH，增加：
当您进行不兼容的 API 更改时的 MAJOR 版本，当您以向后兼容的方式添加功能时的 MINOR 版本，以及当您进行向后兼容的错误修复时的 PATCH 版本。预发布和构建元数据的附加标签可作为 MAJOR.MINOR.PATCH 格式的扩展。
于 2013-12-25T09:52:14.837 回答
1
我使用 VRM，例如 2.5.1
V（版本）更改是主要的重写
R（修订）更改是重要的新功能或错误修复
M（修改）更改是次要的错误修复（错别字等）
我有时也会在最后使用 SVN 提交号。
于 2008-09-25T17:00:38.330 回答
1
归根结底，这一切都是主观的，完全取决于您自己/您的团队。
只需看看所有的答案 - 都非常不同。
我个人使用Major.Minor.*.*- Visual Studio 自动填写修订/内部版本号。这也用于我工作的地方。
于 2009-05-30T10:08:28.167 回答
1
我喜欢年月日。因此，v2009.6.8 将是这篇文章的“版本”。（合理地）复制是不可能的，并且很清楚什么时候是较新的版本。您也可以去掉小数点并将其设为 v20090608。
于 2009-06-08T20:19:56.943 回答
1
对于库，版本号告诉您两个版本之间的兼容性级别，以及升级的难度。
错误修复版本需要保留二进制、源代码和序列化兼容性。
次要版本对不同的项目意味着不同的东西，但通常它们不需要保持源代码兼容性。
主要版本号可以打破所有三种形式。
我在这里写了更多关于基本原理的文章。
于 2010-11-28T17:41:59.457 回答
0
对于内部开发，我们使用以下格式。
[Program #] . [Year] . [Month] . [Release # of this app within the month]
例如，如果我今天发布应用程序#15，并且这是本月的第三次更新，那么我的版本# 将是
15.2008.9.3
这完全是非标准的，但它对我们很有用。
于 2008-09-25T17:25:21.657 回答
0
对于过去的六个主要版本，我们使用了 M.0.mb，其中 M 是主要版本，m 是次要版本，b 是内部版本号。因此发布的版本包括 6.0.2、7.0.1、...，直到 11.0.0。不要问为什么第二个数字总是0；我问了很多次，没有人真正知道。自 1996 年发布 5.5 以来，我们还没有出现过非零值。
于 2008-09-25T17:25:40.703 回答