对于管理软件版本的开源开发人员来说，版本编号逻辑是什么？

Question

我想这是一个普遍的问题，我在任何地方都找不到答案。对于管理软件发行版的开源开发人员来说，版本编号逻辑是什么?我是否可以阅读任何治理或指导。这个问题的起源来自于我在我的Ubuntu操作系统上无数的网站上回顾和研究软件。

通过经验，我了解到一些网站比其他网站更好地解释了一个版本是一个稳定的、实验性的或维护的版本，但是这些解释不符合我熟悉的任何版本编号逻辑。

Answer 1

您可能知道，有不止一个“软件开发方法”。

当然，不止一个“生命周期”。

其中一些是“安全驱动”，一些是“发布驱动”，有些是“截止日期驱动”，“文档驱动”等等。

即使软件是开源的或非开源的，根据项目的目标，软件也可以使用任何方法进行管理。

我认为，最好是搜索项目的方法(如果有，具体的话)，然后搜索它的发行版本控制。

该项目采用瀑布生命周期模型进行管理。这意味着，每一个步骤都被检查，有一个大的工作和团队是分开的某些子团队。(这对开源不好，因为瀑布不是为开放思想而设的)

示例2:项目是用XP管理的，敏捷:这意味着项目是由故事(特性)驱动的。每个子版本都为最新的程序带来了新的和充分发挥作用的特性。每个版本都会带来更大的变化(或者可以一起收集与目标相关的特性)。

Answer 2

我认为这可能值得讨论这个问题的特定版本编号部分。当然，开源项目使用了许多不同的开发模型和版本控制方案。所以没有真正明确的答案，但是有两个项目对Ubuntu非常重要，它们有一个特定的版本编号方法。

GNOME使用版本控制方案，在X.Y.Z中

• "X“是主要的发行编号。只有在项目出现重大中断时，这种情况才会发生变化。
• "Y“是稳定版本的偶数，对于不稳定版本*S是*奇数。例如，3.4.1版本是稳定的，而3.5.1版本是不稳定的。
• "Z“用于”奇数“释放，作为对”偶数“释放的增量。在稳定版本完成后，它将被用于小bug修复“点版本”。

Linux内核使用类似的版本控制方案。对于具有基于时间的版本的项目，这似乎是最有效的。