这是我一直想知道的一个......
请原谅我的幼稚，但是 - 您如何决定为您的软件命名的版本号？
我假设，当有人创建应用程序/程序的“最终”版本时，它是 1.0 版？ - 那么，当你更新它时会发生什么，你如何决定将它称为 1.1 或 1.03 等等。
这主要是给开发者的吗？
【问题讨论】：
标签： version
我最近听说了一个更简洁的版本控制策略，这是我在Eric Elliot's Medium account 首次遇到的。它更侧重于面向客户的版本号的库版本控制，但它具有简单的优势。使用由三部分组成的版本号，其中每个数字表示：
break.feature.fix
我在下面留下我的旧答案，因为它仍然与面向客户的版本相关。
我倾向于将有效数字加权如下......
w.x.y.z（或 w.xyz）
如果您选择使用 w.xyz 格式，则在溢出之前您只能得到 9 位数字。但是，如果您经常发布，您可能会遇到更大的问题。
让我们用我的新产品 FooApp 来说明一下吧！
【讨论】：
Jeff Atwood 对此有一个blog post，他主张只使用日期，而不是让用户与版本号混淆。但是，他确实讨论了 Microsoft 采用的方法：使用日期确定版本号。他在他的帖子中有相当多的深度，所以我不会在这里重复他的工作。至于版本控制：
版本（至少在 .NET 中，类似这样）：
1.2.3.4 其中：
1 是主要版本
2 是次要版本
3 是 build 编号
4 是 修订版 编号
主要版本 - 表示“完整”的系统具有该版本应具有的任何功能。通常，任何后续的“主要”版本都是重写、架构更改或（请原谅冗余）对软件的重大更改。
次要版本 - 表示不太重要的版本，可能包含错误修复、添加的小功能或任何数量的其他“次要”事件。这可能包括界面更改和添加。通常，应用程序在其“主要版本”树中应该有些兼容，因此同一主要版本的次要版本在架构上应该是相同的。
内部版本号 - 通常仅表示错误修复、小修复，并且在其范围内有些微不足道。它可以像改变应用程序的前景和背景之间的对比度一样简单。通常，构建是内部名称，例如每晚构建，因此您总是有一个地方可以恢复到稳定状态。
修订号 - 表示何时发布错误修复或进行了非常小的改进。这些通常仅用于错误修复 - 不包括主要功能增强作为修订。
【讨论】：
我们为任何应用程序的每个构建分配唯一的四部分版本号，定义为 Major.Minor.Maintenance.Build。
主要 - 主要编号与应用程序的重大更改相关联。这个数字还决定了与同一“套件”中其他应用程序的兼容性。当发布新版本时，此数字会增加。这通常意味着发生了重大的架构更改。
次要 - 次要编号与新功能和重大错误修复相关联。每当引入新功能或应用重大错误修复时，此数字将被提前，并且维护编号将设置为零。
维护 - 维护编号与非破坏性错误修复相关联。每当发布仅包含非中断错误修复的版本时，此数字就会增加。
Build - Build 号与编译应用程序的 subversion 变更集（修订号） 相关联。这将提供一种简单的方法来将版本号与 subversion 中的一组精确代码进行匹配。
开发人员对该方案真正感兴趣的唯一数字是Build。数字。通过将 Build 编号与 subversion 修订编号联系起来，我们可以保证使用什么代码来创建发布的应用程序。
【讨论】：
我认为Linux内核是一个很好的参考：
Linux内核的版本号 目前由四个数字组成， 在最近的变化之后 三号长期政策 版本控制方案。为了说明， 假设版本 数字是这样组成的：A.B.C[.D] （例如 2.2.1、2.4.13 或 2.6.12.3）。
* The A number denotes the kernel version. It is rarely changed, and仅当代码发生重大变化时 和内核的概念出现了。 已经改过两次了 内核的历史：1994 年 （版本 1.0）和 1996 年（版本 2.0)。
* The B number denotes the major revision of the kernel. o Prior to the Linux 2.6.x series, even numbers indicate a stable发布，即被认为合适的发布 用于生产用途，例如 1.2、2.4 或 2.6。奇数历史上 一直是开发版本，例如 1.1 或 2.5。他们是为了测试新的 功能和驱动程序，直到它们成为 足够稳定以包含在 一个稳定的版本。这是一个偶数/奇数 版本号方案。 o 从 Linux 2.6.x 系列开始，偶数或奇数没有意义，新的 功能开发正在进行中 相同的内核系列。莱纳斯·托瓦兹 表示这将是模型 可预见的未来。
* The C number indicates the minor revision of the kernel. In the old三号版本控制方案，这个 安全补丁、错误时已更改 修复、新功能或驱动程序是 在内核中实现。随着 然而，新政策只是 当新的驱动程序或功能发生变化 被介绍；小修复是 由 D 号处理。
* A D number first occurred when a grave error, which required immediate修复，在 2.6.8 的 NFS 中遇到 代码。然而，还不够 其他改变合法化 发布新的次要修订版（其中 本来是2.6.9）。所以，2.6.8.1 被释放，唯一的变化 正在修复该错误。和 2.6.11，这被采纳为新的官方版本政策。 Bug修复 现在管理安全补丁 由第四个数字，而更大 更改仅在较小的范围内实施 修订更改（C 编号）。 D 号码也与 编译器的次数 构建内核，因此被称为 “内部版本号”。
另外，有时在版本之后 会有更多的字母，例如 作为“rc1”或“mm2”。 'rc' 是指 发布候选并指示 非官方发布。其他字母 通常（但不总是）是 一个人的首字母。这表明一个 内核的开发分支由 那人。例如ck代表Con Kolivas，ac 代表 Alan Cox， 而 mm 代表 Andrew Morton。 有时，这些字母与 的初级开发区 构建内核的分支，用于 例如，wl 表示无线 网络测试构建。
来自http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering
【讨论】：
无论您选择何种编号方案，务必让您的用户清楚新版本何时与旧客户端代码兼容与新版本何时需要更改现有客户端强>。当客户端代码必须更改时，我知道的大多数项目都会碰到第一个数字。
除了兼容性之外，我也认为使用日期还有很多话要说。尽管像我一样，如果您的发布时间表是每两年一次（但这是针对 1989 年首次发布的工具），那会很尴尬。
【讨论】：
销售或营销人员很可能会决定他们需要一些嗡嗡声。这将确定下一个版本是 1.01 还是 1.1 还是 2.0。在开源中的工作方式相同，但它往往与团队引以为豪的新奇功能相关联。
【讨论】：
A.B.C.D
【讨论】：
这是我在嵌入式 C 项目中用于模块的：
1.00 - 初始版本
1.01 - 小修订
模块没有接口更改（即头文件没有更改）。
任何使用我的模块的人都可以升级而不必害怕破坏代码。
我可能已经做了一些重构或代码清理。
2.00 - 主要修订
模块接口更改（即添加、删除功能或更改某些功能的功能）。升级到此版本很可能会破坏现有代码，并且需要使用此模块重构代码。
我应该补充一点，这是指开发阶段，即模块的内部发布到项目中。
【讨论】：
为了补充以上所有解释，我建议使用版本控制方案，这将使您的客户容易记住并且您可以轻松地为您的软件版本设置基线和管理。此外，如果您支持不同的框架，例如 .Net 1.0、.Net1.1 等，请确保您的版本控制方案也能解决这一问题。
【讨论】：
还有一些很好的信息here..
When to Change File/Assembly Versions
何时更改文件/程序集版本 首先，文件版本和程序集版本不必相互一致。我建议文件版本随着每次构建而改变。但是，不要在每次构建时更改程序集版本，以便您可以区分同一文件的两个版本之间的区别；为此使用文件版本。决定何时更改程序集版本需要对要考虑的构建类型进行一些讨论：运输和非运输。
非发货版本 一般来说，我建议在发货版本之间保持非发货程序集版本相同。这避免了由于版本不匹配而导致的强命名程序集加载问题。有些人更喜欢使用发布者策略为每个构建重定向新的程序集版本。但是，我建议不要将其用于非运输构建：它并不能避免所有加载问题。例如，如果合作伙伴 x 复制您的应用，他们可能不知道安装发布者政策。然后，您的应用程序将被他们破坏，即使它在您的机器上运行良好。
但是，如果同一台机器上的不同应用程序需要绑定到您的程序集的不同版本，我建议为这些构建提供不同的程序集版本，以便可以为每个应用程序使用正确的程序集版本，而无需使用 LoadFrom /等等。
运送构建 至于更改该版本以发布构建是否是一个好主意，这取决于您希望绑定如何为最终用户工作。您希望这些构建是并排的还是就地的？两个版本之间有很多变化吗？他们会破坏一些客户吗？您是否关心它会破坏它们（或者您是否想强制用户使用您的重要更新）？如果是，您应该考虑增加程序集版本。但是，再一次考虑，这样做太多次可能会在用户的磁盘上乱扔过时的程序集。
当您更改程序集版本时 要将硬编码版本更改为新版本，我建议在头文件中为版本设置一个变量，并用该变量替换源代码中的硬编码。然后，在构建期间运行预处理器以放入正确的版本。我建议在发货后立即更改版本，而不是之前，以便有更多时间来发现由于更改而导致的错误。
【讨论】：
如果是库，版本号会告诉您两个版本之间的兼容性级别，以及升级的难度。
错误修复版本需要保留二进制、源代码和序列化兼容性。
次要版本对不同的项目意味着不同的东西，但通常它们不需要保持源代码兼容性。
主要版本号可以打破所有三种形式。
我写了更多关于理由here。
【讨论】：
这取决于项目。下面是 haskell 的包版本控制政策。
-- The package version. See the Haskell package versioning policy (PVP)
-- for standards guiding when and how versions should be incremented.
-- http://www.haskell.org/haskellwiki/Package_versioning_policy
-- PVP summary: +-+------- breaking API changes
-- | | +----- non-breaking API additions
-- | | | +--- code changes with no API change
version: 0.1.0.0
【讨论】：