早期版本号如何适用于新产品？

我目前正在为朋友编写一个小型桌面应用程序，但主要是为了给自己学习。本着受过良好教育和按正确方式做事的精神，我希望拥有此应用程序的版本号。

我的研究提出了这些相关结果

• 您使用什么“版本命名约定”？
• 您如何对文件进行版本控制（版本号）
• 分叉的项目，我的版本号从哪里开始？

但它们都没有解决Alpha，Beta，发行候选版本和＆c的编号。版本号低于1.0的约定是什么？我知道他们可以继续一段时间；例如，PuTTY已经存在了至少十年，仍然仅处于beta beta 0.60版本。

这确实取决于项目；有些项目甚至没有发布1.0版。

MAME的开发人员不打算发布其模拟器程序的1.0版。争论是，它将永远不会真正地“完成”，因为总是会有更多的街机游戏。0.99版本后面紧跟着0.100版本（次要版本100> 99）。以类似的方式，Xfire 1.99之后是1.100。经过6年的开发，eMule甚至还没有达到0.50版本。^{Wikipedia上的软件版本控制}

一种流行的版本编号方法（我已经开始使用）是Semantic Versioning。

在这种方案下，版本号及其更改方式传达了有关底层代码以及从一个版本修改到另一个版本的含义。

一些引号为您提供有关其工作原理的更多想法和/或回答您的一些问题：

我怎么知道什么时候发布1.0.0？

如果您的软件正在生产中使用，则可能已经是1.0.0。如果您拥有用户依赖的稳定API，则应为1.0.0。如果您担心向后兼容性，那么您应该已经是1.0.0。

这不妨碍快速开发和快速迭代吗？

零主要版本是关于快速发展的。如果您每天都在更改API，则您应该仍处于0.xx版本中，或者位于一个单独的开发分支中，该版本致力于下一个主要版本。

如果即使对公共API的最小的向后不兼容的更改也需要重大的版本改进，我是否会很快以42.0.0版结束？

这是负责任的发展和远见的问题。具有很多相关代码的软件不应轻易引入不兼容的更改。升级必须产生的成本可能是巨大的。必须修改主要版本以发布不兼容的更改意味着您将考虑更改的影响，并评估所涉及的成本/收益比。

还有关于如何指定“ alpha”，“ beta”等版本的规则。在http://semver.org/上查看详细信息。

[编辑]另一个有趣的版本编号方案是MongoDB使用的一种：

MongoDB使用奇数版本进行开发发行。

MongoDB版本中有3个数字：ABC

• A是主要版本。这种情况很少会改变，而意味着非常大的改变
• B是发行号。这将包括许多更改，包括功能和可能破坏向后兼容性的内容。偶数B将成为稳定的分支，奇数B将成为发展。
• C是修订号，将用于错误和安全性问题。

例如：

• 1.0.0：第一个GA版本
• 1.0.x：修正至1.0.x的错误-强烈建议进行升级，风险很小
• 1.1.x：开发版本。这将包括尚未完全完成且仍在进行中的新功能。有些事情可能与1.0不同
• 1.2.x：GA的第二版。这将是1.1.x版本的高潮。

我认为没有这样的“标准”。

发行候选者有一个约定，通常是“ [RC 1版]”，具体取决于您认为可能发行的版本数。

如果要发布的产品的早期版本（功能不完整的版本），则可能要使用版本“ 0”。这样，您可以在填写功能集时随时间增加版本。

我会使用“候选版本”之类的“ Alpha”和“ Beta”作为时间限制版本，以表示您认为您即将发布完整版本。

Wikipedia页面上有Software Versioning。对于共享1.0之前的版本，Apple和其他公司使用的约定效果很好：major.minor.maintSrev，其中S是预发布版本的阶段指示器：d =开发，a = alpha，b = beta，rc =候选发布。因此，您的第一个内部版本可能是1.0.0d1。

对于完全内部修订，时间戳是足够的。

每个开发人员大部分都会决定要使用的标准。通常，尽管小数点左边的数字表示较大的修订版本，对于普通用户而言可能非常明显（例如功能或界面更改等）。在小数点的右边，这是一个更改/修改/添加，它不会改变整体功能和设计，但是确实改变了程序本身（例如，使功能更快，同时仍在执行相同的操作或修复）安全问题）。然后，如果您添加其他小数点，则这些数字右边的数字将表示更改越来越小（即较小的错误修复/安全性问题等）。

正如其他人所说，似乎没有确切的标准。我们的组织使用以下符号：

版本1.0 ---> 2.0（产品中新增的一项重大新功能/改进功能）

版本1.0 ---> 1.1（向产品添加了中等级别的新功能/改进功能）

版本1.0 ---> 1.001（Bugfixes）

“ 1.0版”里程碑对于有经验的计算机用户非常重要，因为它暗示程序已完成并且可以按预期工作。版本“ 0.something”中的任何内容都表示程序员本身认为该程序尚未完成。

您可以保留功能重大成就的“ 0.1”，“ 0.2” ...版本号，然后使用内部版本号（通常是足够精细的日期和时间戳）对其进行子集化。