寻找相关软件组件的版本编号的最佳实践

我们正在尝试确定一种对彼此依赖的软件组件进行版本编号的好方法。

让我们更具体一点：

软件组件A是在嵌入式设备上运行的固件，而组件B是其在普通PC（Linux / Windows计算机）上的驱动程序。他们正在使用自定义协议相互通信。由于我们的产品还面向开发人员，因此我们将提供两个组件的稳定和不稳定（实验）版本（固件是封闭源代码，而驱动程序是开放源代码）。我们最大的困难是如何处理通信协议中的API更改。

在驱动程序中实施兼容性检查时-它检查固件版本是否与驱动程序版本兼容-我们开始讨论版本编号的多种方式。

我们提出了一个解决方案，但我们也想重新发明轮子。这就是为什么我希望从程序员/软件开发人员社区获得一些反馈的原因，因为我们认为这是一个普遍的问题。

所以这是我们的解决方案：

我们计划遵循广泛使用的major.minor.patch版本编号，并对稳定/不稳定版本使用偶/奇次编号。如果我们在API中引入更改，则会增加次要编号。

此约定将导致以下示例情况：

当前稳定分支为1.2.1，不稳定分支为1.3.7。现在，针对不稳定的新补丁更改了API，这将导致新的不稳定版本号变为1.5.0。一旦不稳定分支被认为是稳定的，例如在1.5.3中，我们将其发布为1.4.0。

对于以下任何相关问题的答案，我都会感到高兴：

• 您可以提出解决上述问题的最佳做法吗？
• 您认为我们的“习惯”约定好吗？
• 您将对上述约定进行哪些更改？

恕我直言，版本号类似于产品名称；重要的是它们是可见的，但不重要的是它们是装饰而不是内容。

版本号仍然像产品名称一样带有含义。您可以做的最重要的事情就是避免混乱。因此，这是有关版本号的一些常见期望。如果不满足这些例外，则用户可能会感到困惑：

版本号单调增加
这可能是最明显的期望，同时最不可能是真实的。在一览，用户期望版本2.3.5来后 2.2.17版本，并且具有相同或更好的技术。但是，当然2.3.x是开发分支，而2.2.x是稳定的，而2.3.5实际上是在2004年发布的，而2.2分支仍在积极地工作中，而2.2.17刚在去年4月发布并包含。 .. 反正你懂这个意思。您也可以仅将2.2版本的“马铃薯”称为该数字的所有含义。欢迎使用版本“ Potato-17 ”！

相似的版本是可升级/兼容的
如果我的计算机上安装了3.7版，并且所有新的闪亮的frozbots都附带了3.8版，则我希望通过进行某些升级或补丁或其他操作，我的3.7可以成为3.8版而不会受到干扰。但是，如果我使用3.7，而您发布5.2，则我并不那么乐观。当然，我宁愿惊喜而不是失望。

如果Java在这个问题上没有那么明显地令人困惑，那么第一位数字是很重要的，我什至不愿意提到这一点。除非有人告诉您，否则您不会指望“ Java 7”实际上是1.7版。第一次听到这个消息时，您几乎肯定会回答：“ 什么？。为什么？ ”

显然，纯粹主义者会说，仅当平台更改不向后兼容时，主版本号才会更改。但是，你真的打算放弃向后兼容性不断？主要版本的转速通常是一项营销决定，而不是技术决定；Java的荒谬性来自两个阵营，两种方式同时发挥作用，几乎达到可笑的效果。

最后，
正如我刚才提到的，版本号通常与营销有关，而与技术有关。没关系，因为那是用于什么版本号的：通知您有关该软件的最新信息。数量大变化意味着功能大变化。少量更改意味着几乎没有功能更改。这就是人们的期望。是否为真，确定您的版本号是否具有与用户认为的相同的含义。

-编辑-
我忘了提及这一点，但Caleb很好地指出了这一点：不要使用版本号来表示任何重要的内容（例如，稳定/不稳定），除非在其他地方将其明确表示出来。是的，您知道奇特的次要版本号表示开发，但这使我们成为其中的一员。Debian的“不稳定”发行名字就是一个很好的例子。或者您也可以使用完全独立的产品名称；产品名称为“ Frozbot 1.2”，开发版本为“ Devbot 1.3”。

一旦不稳定分支被认为是稳定的，例如在1.5.3中，我们将其发布为1.4.0。

不，不。对于不稳定的1.5.3，稳定必须从1.6.0开始（如果要使用语义版本控制，则刚错过1.4.x）

您试图使用一个值来表示两个独立的事物。

首先，您有一个“版本”，通常用于标识各种发行版并指示发行的顺序。正如tylerl所说，该版本应始终增加-如果您将版本从1.5.3更改为1.4.0，则对用户没有任何意义（并且也可能引起很多内部混乱）。

其次，您试图指出给定版本是否稳定。

这是可能的，表示这两件事有一个“版本号，”就像有些店会用一些定价方案，以指示项目是否有售。例如，在我附近的商店中以'3'结尾的价格是最终销售价格。这对员工很有效，他们很快就学会了如何确定销售价格，但这不是告诉客户销售情况的好方法。因此，他们还在销售商品附近贴上标语。您可以执行类似的操作，例如，将稳定版本的最低有效位数设为偶数，将实验版本的最低有效位数设为奇数。不过，我认为，如果要发布具有实验意义的内容，则应以这种方式明确标记。您可以在版本字符串的开头或结尾添加“ X”，例如：X.1.5.31.5.3.X。之后，您甚至可以提供实验版本号，因此您可以基于相同的基本版本发布多个实验版本：1.5.3.X1，1.5.3.X2。

你也应该考虑到有使用“阿尔法”和“贝塔”的版本号的悠久传统，以表明可能不稳定或完整版本：1.5.3a54。如果您决定执行其他任何操作，请确保有充分的理由偏离此方案，因为您可能必须向开发人员社区解释其他任何内容。

我建议使用major.minor.patch格式，对稳定/不稳定版本使用扩展名“ tag”，并确定主编号和次编号的明确含义：

major.minor.patch-stable|unstable

哪里

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

这样，就可以轻松管理依赖项，并在每个组件客户端/用户必须更加注意新版本时告诉它们。例如，如果组件A（对1.1.0稳定）依赖于B（对5.4.534稳定），并且要发布B的新版本（对6.1.0不稳定），则立即意识到必须将A进行更改，可能实质上是。

我真的很喜欢Hibernating Rhinos一直在构建RavenDb相对于版本的方式-它们的内部版本号不断增加。当他们得到稳定的东西时，它就被标记为稳定的。但是，一切都适合发布。