哪些开源项目使用奇数不稳定/偶数稳定的版本控制风格
我的一位同事今天告诉我，有些项目使用一种奇怪的（恕我直言）方式对其版本进行版本控制。如果版本不稳定，次要版本为奇数，例如。 1.3、1.5。另一方面，稳定版本有一个甚至较小的版本号，例如。 1.2、1.4。
起初我简直不敢相信自己的耳朵，感觉很不真实。然后 Wikipedia 启发我，这是来自 Linux 内核社区的实践，尽管似乎（？）最近被删除了。
几个小时后，我正在阅读Programming Ruby's preface，我该怎么办看？ Ruby 对版本号使用相同的约定。
您对此有什么经验？您知道哪些（开源）项目/产品使用此版本控制架构？如果他们遵守这个惯例，有没有一种简单的方法可以快速弄清楚？有那么受欢迎吗？我三年多前开始软件开发，之前从未听说过这种做法。
感谢您的回复。
One of my colleagues told me today that some projects use a weird, IMHO, way of versioning their releases. If the release is unstable, the minor version is an odd number, eg. 1.3, 1.5. On the other hand, stable releases have an even minor version number, eg. 1.2, 1.4.
At first I couldn't believe my ears, it seemed unreal. Then Wikipedia enlightened me that it is a practice coming from the Linux kernel community, although it seems(?) to have been dropped recently.
A few hours later, I'm reading Programming Ruby's preface, and what do I see? Ruby uses the same convention for version numbers.
What's your experience with this? What (open-source) projects/products you know of that use this versioning schema? Is there an easy way to figure it out quickly if they observe this convention? Is it that popular? I've begun software development a little more than 3 years ago and haven't heard about this practice before.
Thanks for your responses.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
随着 2003 年 2.6 内核的推出，Linux 内核放弃了这种做法（即 2.4 是最后一个稳定版，并有相应的 2.5 开发分支）。我只是查了一下我在硕士论文 关于项目的一般情况：
有关 Linux 内核的更多详细信息，请随意阅读整个“2.2.4 Linux 开发分支”章节。
编辑：原始链接已消失，这里是 新链接和正确的引用：
The linux kernel dropped that practice with the start of the 2.6 kernel in 2003 (i.e. 2.4 was the last stable with a corresponding 2.5 development branch). I just looked up what I wrote in my master thesis about projects generally:
For more details about the linux kernel, feel free to read the whole "2.2.4 Linux development branches" chapter.
EDIT: The original link has gone away, here is a new link and proper citation:
许多开源项目确实使用了这种方法，但大多数已经改为其他方法。例如，Linux 内核曾经这样做过（很久以前）。最近，Mesa（Linux 的开源 OpenGL 堆栈）在 2.5 版本中停止使用此方法。
恕我直言，所有版本都应该相对稳定。如果尚未稳定，则应该是 alpha 或 beta 版本。例如，KDE 4.0 的发布就是一个可怕的错误。 4.0应该是alpha版本。 4.1 应该是测试版。 4.2 是第一个真正可用的版本。
Many open source projects did use this, but most have changed to other methods. For example the Linux kernel used to do this (quite a while ago). Recently, Mesa (the open source OpenGL stack for Linux) stopped using this method with version 2.5.
IMHO, all releases should be relatively stable. If it is not yet stable it should be an alpha or beta release. For example, the KDE 4.0 release was a terrible mistake. 4.0 should have been alpha. 4.1 should have been beta. 4.2 was the first really usable release.
GTK+ 和 GNOME 也使用该版本控制方案。请注意，自 1.9（稳定）以来，ruby 不再使用此方案。
GTK+ and GNOME also use that versioning scheme. Note that ruby does not use this scheme anymore since 1.9 (which is stable).