versioning - 我可以提供一些版本编号建议吗？

Question

我们的产品历史悠久（12年左右）。

它起源于 VB3（第 1 版）和后来的 VB6（第 2 版）。（版本号是“狗早餐”，版本控制是一场噩梦。

我已经在这里参与了几年了。我们在 .Net 平台上正在开发第 3 版，但第 2 版继续得到定期发布的支持 - 每年大约 3 或 4 次。

我在开始时引入了夜间自动化构建，我们产品的版本号是 2.2.2。每个人都计划只发布 2.2.3，但是自动构建过程和 VB6 的“有趣”的 3 部分编号系统意味着我们需要使用第三部分 - 构建/修订号 - 它应该是。

所以我们发布了 2.3 版（内部版本号为“whatever”）并开始使用 2.4（每晚增加内部版本号），然后是 2.5，然后是 2.6，等等。

内部版本号隐藏在公众视野之外，但可用于支持目的，即使我们很少发布超过一个版本的版本 - 但我们偶尔需要修补。

确保一致性。现在我们达到 2.9。我们即将移动到 2.10（2 点 9，最多 2 点 10）。不幸的是，非技术人员将其视为有理数（两点一）。他们无法理解我们为什么不直接使用 3.0 版——比如数数。（内部版本号仅出于支持目的显示在“帮助/关于”屏幕上）。

我认为没有必要对产品（主要数量）进行升级，尤其是由于市场对这将设定的期望。

这里有正确的方法吗？（2.10 或 3.0 或更好的版本 - 或者它甚至重要吗？）

（注意。我已经竭尽全力确保版本号现在显示为 2.09，而不是 2.9（在我们的网站、产品启动屏幕和各种其他公共场所等），因此当我们移动到 2.10 时，它可能更有意义，但这可能同样令人困惑，因为 2.09 实际上是比 2.8 更低的有理数......）

也可以看看：

确定版本号

版本号怎么做？

你怎么知道要使用什么版本号？

score 9 · Accepted Answer

将其视为非技术人员学习一些东西的机会；-) 版本号应该就像一本书中的章节号，它们将您的程序的生命周期分成连贯且内部一致的块。

score 6 · Accepted Answer

如何对自己的软件进行版本控制取决于您。没有“对”或“错”之分，除了在考虑维护、发布管理和客户支持的观点后最好的选择。对你来说重要的是控制版本控制——你理解它，使用该产品的每个人都理解它，并且它不会在以后引起问题。与 3.0 相比，从 2.9 升级到 2.10 没有任何意义，除了你赋予它的意义。

score 6 · Accepted Answer

其他答案只对了一半。版本号具有您赋予它们的含义，但它们也具有其他人赋予它们的含义。你自己的意思真的不重要，因为你不会去纠正你的用户。如果他们认为从 2.9 升级到 3.0 是一个巨大的飞跃，那么他们就会接受它。如果他们害怕使用 x.0 版本，那么他们不会。如果他们习惯于使用 alpha 版本的奇数版本，那么他们将不会使用这些版本。

尽管我不想这么说，但版本号是一种营销工具。他们向用户说明了有关版本的信息，因此您在选择版本号时必须考虑到这一点。

问题是，版本号对不同的人意味着不同的东西。有些事情你可以预测。正如我上面提到的，人们会怀疑 x.0 版本。他们预计 2.x 到 3.x 会有很大的变化。如果您想尝试播放，请继续。

版本号有两个基本属性。首先，它们必须始终上升。其次，它们必须易于分类。第一个是显而易见的，但第二个经常被违反。考虑版本 2.9 -> 2.10。从数值上讲，2.9 大于 2.10。您必须考虑它们的主要/次要版本号才能正确排序。由此产生了关于 2.10 或 3.0 是否遵循 2.9 的混淆。即使我们知道排序规则，它似乎仍然是错误的。出于这个原因，我总是填充我的版本。2.09 之后是 2.10。它以数字和点对的形式正确排序。

这仍然让用户试图从版本号中推测含义，就像命理学家筛选中奖号码一样。你可以尝试玩那个游戏，或者你可以离开它。为什么要使用点对呢？使用整数。这是明确的。它排序微不足道。它没有为用户提供任何错误的含义。

我可以去一个更好的。您可以赋予版本号明确的含义，这是有用的东西。我们在CPAN世界中遇到的一个问题是人们没有升级他们的模块，因为他们使用的是 1.03 版本，而最新版本是 1.07，看起来，只有 0.04 的差异。为什么要升级？它没有显示在 1.03 和 1.07 之间有四年。微软发现了这一点，这就是我们购买 Office 2009 而不是 Office 12 的原因（如果你不经常发布它也会咬你一口，谁会想要 2001 年的 Windows 98？）它就在版本号中。“Widgets 2007”告诉你也许你应该去寻找升级。

我曾经使用 ISO 日期作为版本。如果您今天发布，它将是版本 20090309。如果您必须在一天内发布两个，请在末尾添加小时和分钟：20090309.2051。这很容易。它总是上升。它向用户传达了一些关于发布的明确含义。这是一个例子。

我现在使用语义版本控制。它使用点三元组来传达三个重要的信息。API被破坏了吗？是否添加了功能？这只是一个错误修复吗？用户必须知道您的项目正在使用语义版本，这是 ISO 日期版本的劣势。优点是它传达的信息类型并且定义明确。

score 5 · Accepted Answer

我建议始终在您的版本号中使用至少 3 个组件，并且除了第四个或更多组件之外不要隐藏任何内容。到处都遵守这个约定，因为对于非技术人员来说很明显，这不可能是一个有理数，它必须是其他东西（即三个整数的复合物）。

2.8.0
2.9.0
2.10.0
2.11.0
...

此外，在关于对话框中，将构建日期 (yyyy-mm-dd) 粘贴在版本号附近。如果客户对版本号感到困惑，他/她可以直接比较日期，这对于普通人来说更直观。

score 4 · Accepted Answer

4

你可以做 2.9.1 甚至 2.10.1，但是有很多项目一直在计数。2.10、2.11 12 13 等

于 2009-03-10T00:28:29.743 回答

score 3 · Accepted Answer

我认为您通过走向 2.10 追求了正确的方法。版本号的主要目的应该是将新功能和开发分组为可定义的发布版本。如果您的编号妨碍了这一点，您需要一个不同的编号方案。

score 3 · Accepted Answer

3

如果 2.10 引起混乱，则跳过它并转到 2.11。准备好用 2.20 解决同样的问题 :)

于 2009-03-10T01:14:02.037 回答

score 2 · Accepted Answer

我建议将您的营销版本与您的 DLL 的内部版本和诸如此类的东西分离。它们有不同的语义。

score 1 · Accepted Answer

Wikipedia 有关于软件版本控制的非常好的文章

如果您正在处理长期持续的项目，则基于序列的标识符（如 1.0、2.0 等）无法扩展。

我个人喜欢（并且更喜欢）在其版本中使用发布年份和月份的 Ubuntu 版本控制方案。例如，Ubuntu 8.04 于 2008 年 4 月发布。

score 1 · Accepted Answer

谢谢 - 这里有很多很棒的答案。

我有“接受答案焦虑”-但我认为从每个答案中取一点可能是正确的。

首先，这里没有对错。其次，编号不应该妨碍任何事情。

版本编号可以被认为是一本书中的章节和章节编号——这将真正帮助我向其他人解释，至少是我的想法。

将营销版本控制与技术/开发版本编号分开/分离将解决所有问题……不过，这是一个长期的答案。

我坚持使用 2.10 来遵循 2.9 - 我会继续战斗......并且肯定会调查 Ubuntu

score 1 · Accepted Answer

您应该告诉他们以独立于内部版本号的方式标记软件版本。例如，iPhoto '09 是 iPhoto 8.x 版。微软也做了同样的事情。

显然，主要供应商已经转向与功能发布有关的品牌版本，同时允许开发人员更自由地使用他们的版本号。这让每个人都满意，营销人员会特别高兴，因为他们会想出一个全新的策略来为软件版本打上品牌。

score 0 · Accepted Answer

我不会使用主要版本号来表示完全重写。重写是如此罕见，以至于对于很多员工来说，你只需要解释第 1 版是“在你在这里工作之前”。如果您的产品被称为“堆栈溢出”，那么我只需将重写称为“堆栈溢出”，将较旧的产品称为“旧堆栈溢出”。这可以不断提醒旧版本的用户他们需要迁移。

versioning - 我可以提供一些版本编号建议吗？

12 回答 12

Related

Reference