【发布时间】：2010-09-13 04:00:45
【问题描述】：
我在线分发软件，并且一直想知道是否有合适的方法来更好地定义版本号。
让我们假设答案是 A.B.C.D。什么时候增加每个组件？
您是否使用任何其他版本号技巧，例如 D mod 2 == 1 意味着它仅是内部版本？
您是否有带有自己版本号的 beta 版本，或者您是否有每个版本号的 beta 版本？
【问题讨论】：
标签： release release-management release-cycle
【发布时间】：2010-09-13 04:00:45
【问题描述】：
我开始喜欢某些应用程序（例如 Perforce）使用的 Year.Release[.Build] 约定。基本上它只是说明你发布的年份，以及那一年的顺序。所以 2008.1 将是第一个版本，如果您再过一三个月发布另一个版本，它将转到 2008.2。
这种方案的优点是没有隐含的发布“数量”，您可以在其中争论某个功能是否足够重要以保证主要版本增加。
一个可选的附加功能是标记内部版本号，但这往往仅用于内部目的（例如，添加到 EXE/DLL 以便您可以检查文件并确保存在正确的版本）。
【讨论】：
-
另一个好的方案是使用这种格式的构建日期：YYYY.MM.DD.BuildNumber，其中 BuildNumber 是一个连续的数字（更改列表）或者只是每天从 1 开始。示例：2008.03.24.1 或 2008.03.24.14503。
-
这主要用于内部版本，如果您不经常每月发布一次（或将维护版本标记为 2008.03a 2008.03b 和等等）。
-
为了更加用户友好，请以友好的格式打印月份，例如“2008 年 3 月”。
-
小心！这个策略将在 65536 年失败！ :)
在我看来，几乎任何版本号方案都可以或多或少地正常工作。我工作的系统使用版本号，例如 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 提供了Software Release Practice HOWTO，包括有关命名（编号）版本的（链接）部分。
【讨论】：
我通常使用 D 作为构建计数器（编译器自动递增） 每次将构建发布到“公共”时，我都会增加 C（不是每个构建都发布） A 和 B 用作主要/次要版本号并手动更改。
【讨论】：
我认为有两种方法可以回答这个问题，它们并不完全互补。
- 技术：根据技术任务增加版本。示例：D 是内部版本号，C 是迭代，B 是次要版本，A 是主要版本。定义次要版本和主要版本确实是主观的，但可能是相关的事情，例如对底层架构的更改。
- 营销：根据向客户提供的“新”或“有用”功能的数量增加版本。您还可以将版本号与更新策略联系起来...对 A 的更改需要用户购买升级许可证，而其他更改则不需要。
我认为，最重要的是找到适合您和您的客户的模型。我见过一些情况，其中偶数版本是公开版本，而奇数版本被认为是 beta 或开发版本。我见过一些同时忽略 C 和 D 的产品。
然后是来自 Micrsoft 的示例，其中对 .Net Framework 版本号的唯一合理解释是涉及营销。
【讨论】：
我们的政策：
- A - 显着 (> 25%) 变化或 增加功能或 界面。
- B - 小改动或 增加功能或 界面。
- C - 小的改动 打破界面。
- D - 修复了一个 构建不改变 界面。
【讨论】：
-
C 语言中的重大更改？我想你在这里交换了 B 和 C。重大更改比小的更改和添加更重要。
-
不，没错。功能定义了版本号。 （这主要是营销，记住）。破坏接口只是内部利益，通常是次要的——除非它们增加了功能。
人们往往想让这件事变得比实际需要的困难得多。如果您的产品只有一个长期存在的分支，只需按其内部版本号命名后续版本。如果你有某种“小错误修复是免费的，但你必须为主要的新版本付费”，那么使用 1.0、1.1 ... 1.n、2.0、2.1...等。
如果您不能立即弄清楚示例中的 A、B、C 和 D 是什么，那么您显然不需要它们。
【讨论】：
-
人们可以弄清楚，但也许有比他们使用的更具体的原因或更合适的方法。并且也许还有一些有用的技巧，例如定义发布或调试版本的奇偶校验位。
我对版本号的唯一用途是让客户告诉我他们使用的是 2.5.1.0 或其他版本。
我唯一的规则是尽量减少报告该数字时的错误：所有四个数字都只能是 1 位数字。
1.1.2.3
没问题，但是
1.0.1.23
不是。客户可能会将这两个数字（至少口头上）都报告为“一一二三”。
自动递增的内部版本号通常会产生类似的版本号
1.0.1.12537
这也无济于事。
【讨论】：
一个好的非技术方案只是使用这种格式的构建日期：
YYYY.MM.DD.BuildNumber
其中 BuildNumber 是一个连续的数字（更改列表）或每天从 1 开始。
示例：2008.03.24.1 或 2008.03.24.14503
这主要用于内部发布，如果您不经常发布每月一次，公开发布的版本会打印为 2008.03。维护版本被标记为 2008.03a 2008.03b 等等。他们应该很少超过“c”，但如果它是一个很好的指标，你需要更好的 QA 和/或测试程序。
用户常见的版本字段应以友好的“2008 年 3 月”格式打印，在“关于”对话框或日志文件中保留更多技术信息。
最大的缺点：只是在另一天编译相同的代码可能会更改版本号。但是您可以通过使用版本控制更改列表作为最后一个数字并检查以确定是否也需要更改日期来避免这种情况。
【讨论】：
在 github 世界中，遵循 Tom Preston-Werner 的版本号“semver”规范已变得很流行。
给定版本号 MAJOR.MINOR.PATCH，增加：
进行不兼容的 API 更改时的主要版本，次要版本 当您以向后兼容的方式添加功能时，以及 PATCH 进行向后兼容的错误修复时的版本。额外的 预发布和构建元数据的标签可作为扩展使用 转为 MAJOR.MINOR.PATCH 格式。
【讨论】：
我使用 V.R.M，例如2.5.1
V（版本）更改是重大改写
R（修订）更改是重要的新功能或错误修复
M（修改）更改是小错误修复（错别字等）
我有时也会在末尾使用 SVN 提交号。
【讨论】：
归根结底，这一切都非常主观，完全取决于您自己/您的团队。
只要看看所有的答案 - 都非常不同。
我个人使用Major.Minor.*.* - Visual Studio 自动填写修订/内部版本号。这也用于我工作的地方。
【讨论】：
我喜欢 Year.Month.Day。 所以，v2009.6.8 将是这篇文章的“版本”。 （合理地）复制是不可能的，并且很清楚什么时候是较新的版本。您也可以去掉小数点并将其设为 v20090608。
【讨论】：
如果是库，版本号会告诉您两个版本之间的兼容性级别，以及升级的难度。
错误修复版本需要保留二进制、源代码和序列化兼容性。
次要版本对不同的项目意味着不同的东西，但通常它们不需要保持源代码兼容性。
主要版本号可以打破所有三种形式。
我写了更多关于理由here。
【讨论】：
对于内部开发，我们使用以下格式。
[Program #] . [Year] . [Month] . [Release # of this app within the month]
例如，如果我今天发布应用程序#15，并且这是本月的第三次更新，那么我的版本# 将是
15.2008.9.3
这完全不标准，但对我们很有用。
【讨论】：
对于过去的六个主要版本，我们使用了 M.0.m.b，其中 M 是主要版本，m 是次要版本，b 是内部版本号。因此发布的版本包括 6.0.2、7.0.1、...，直到 11.0.0。不要问为什么第二个数字总是0；我问了很多次，没有人真正知道。自 1996 年发布 5.5 以来，我们还没有出现过非零值。
【讨论】：