这是我一直想知道的......
请原谅我的天真，但是 - 您如何确定用于命名软件的版本号？
我假设，当有人创建应用程序/程序的“最终”版本时，它是版本1.0？ - 然后，当你更新它时会发生什么，你如何决定称它为1.1或1.03等等。
这主要是针对开发人员的吗？
答案 0 :(得分：47)
我最近听说过我在Eric Elliot's Medium account遇到的一个简单的版本控制策略。对于面向客户版本号的库版本更加重视，但它具有简单的优势。使用三部分版本号，其中每个数字表示：
<强> breaking.feature.fix
我在下面留下我的旧答案，因为它仍然与面向客户的版本相关。
我倾向于对有效数字进行加权，如下所示....
w.x.y.z（或w.xyz）
如果您选择使用w.xyz格式，则溢出前只能获得9位数字。但是，如果你经常发布，那么你可能会遇到更大的问题。
让我们用我的新产品FooApp来说明！
答案 1 :(得分：24)
杰夫阿特伍德有一个blog post关于这一点，他提倡只使用日期，而不是将用户与版本号混淆。但是，他确实讨论了Microsoft采取的方法：使用日期来确定版本号。他在帖子中进入了相当深度，所以我不会在这里复制他的作品。至于版本控制：
版本（至少在.NET中，就是这样）：
1.2.3.4其中：
1是主要版本
2是次要版本
3是构建号码
4是修订号码
主要版本 - 表示具有该版本所具有的任何功能的“完整”系统。通常，任何后续的“主要”版本都是重写，或架构更改，或（原谅冗余）软件的主要更改。
次要版本 - 表示不太重要的版本，可能有错误修复，添加了小功能或任何其他“次要”事件。这可能包括界面更改和添加。通常应用程序应该在它们的“主要版本”树中有些兼容，因此同一主要版本的次要版本在架构上应该是相同的。
内部版本号 - 通常只表示错误修复，小修复，并且在其范围内有些微不足道。它可以像改变应用程序的前景和背景之间的对比一样简单。通常，构建是内部指定，例如每晚构建，因此您总是有一个地方可以恢复到稳定。
修订号 - 表示何时发布错误修复或进行了非常小的改进。这些通常仅用于修复错误 - 不包括主要功能增强功能作为修订。
答案 2 :(得分：8)
我们为任何应用程序的每个版本分配唯一的四部分版本号，定义为 Major.Minor.Maintenance.Build 。
专业 - 主要编号与应用程序的重大更改相关联。此数字还确定与同一“套件”中的其他应用程序的兼容性。新版本发布时，此数字会递增。这通常意味着发生了重大的架构变化。
次要 - 次要号码与新功能相关联并修复错误修复。无论何时引入新功能或应用破解错误修复，此数字都将提前，维护编号将设置为零。
维护 - 维护号与不间断的错误修复相关联。只要发布的版本仅包含非中断错误修复，该数字就会被提前。
构建 - 构建号与编译应用程序的subversion变更集（修订号）相关联。这将提供一种简单的方法，将版本号与subversion中的一组精确代码进行匹配。
开发人员对此方案真正感兴趣的唯一数字是构建。数。通过将构建编号绑定到subversion版本号，我们可以保证使用了哪些代码来创建已发布的应用程序。
答案 3 :(得分：7)
我认为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系列开始，使用new对偶数或奇数没有意义 功能开发正在进行中 相同的内核系列。 Linus Torvalds有 声明这将是模型 可预见的未来。
* The C number indicates the minor revision of the kernel. In the old三号版本控制方案，这个 当安全补丁，bug被改变了 修复，新功能或驱动程序 在内核中实现。随着 然而，新政策只是 在新的驱动程序或功能时更改 介绍;小修正 由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代表安德鲁莫顿。 有时候，这些字母与之相关 的主要发展领域 分支内核是为了构建的 例如，wl表示无线 网络测试构建。
来自http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering
答案 4 :(得分：3)
无论您选择哪种编号方案，当新版本与旧客户端代码兼容时，向新用户明确要求更改现有客户端时，向用户明确至关重要 STRONG>。我知道的大多数项目都会在客户代码发生变化时碰到第一个数字。
除了兼容性之外，我也认为使用日期有很多话要说。如果和我一样，你的发布计划是每两年一次（但这是1989年首次发布的工具），那会很尴尬。
答案 5 :(得分：2)
销售或营销方面的某些人很可能会认为他们需要一些嗡嗡声。这将确定下一个版本是1.01还是1.1或2.0。开源中的工作方式相同，但它往往与团队引以为豪的新功能相关联。
答案 6 :(得分：2)
A.B.C.D
答案 7 :(得分：2)
这是我在嵌入式C项目中用于模块的内容：
1.00 - 初始版本
1.01 - 次要修订版 没有接口改变模块（即头文件没有改变）。 使用我的模块的任何人都可以升级，而不必害怕破坏代码。 我可能已经做了一些重构或代码清理。
2.00 - 重大修订 模块接口已更改（即添加，删除功能或更改某些功能的功能）。升级到此修订版很可能会破坏现有代码，并且需要使用此模块重构代码。
我应该补充一点，这指的是开发阶段，即模块内部发布到项目中。
答案 8 :(得分：2)
为了添加上述所有解释，我建议使用版本控制方案，让您的客户能够轻松记住并轻松地进行基线和管理软件版本。此外，如果您支持不同的框架，如.Net 1.0，.Net1.1等，那么请确保您的版本控制方案也照顾它。
答案 9 :(得分：1)
一些好的信息here以及......
When to Change File/Assembly Versions
何时更改文件/程序集版本 首先，文件版本和汇编版本不需要相互重合。我建议每个版本都会更改文件版本。但是，不要只为每个构建更改程序集版本，以便您可以区分同一文件的两个版本;使用文件版本。决定何时更改程序集版本需要考虑要考虑的构建类型：运输和非运输。
非运输建筑 通常，我建议在运输版本之间保持非运输组件版本相同。这避免了由于版本不匹配而导致强烈命名的程序集加载问题。有些人更喜欢使用发布者策略来重定向每个构建的新程序集版本。但是，对于非运输版本，我建议不要这样做：它不能避免所有加载问题。例如，如果合作伙伴对您的应用进行x复制，则他们可能不知道安装发布商政策。然后，即使它在您的计算机上运行正常，您的应用也会被破坏。
但是，如果有同一台机器上的不同应用程序需要绑定到程序集的不同版本，我建议为这些版本提供不同的程序集版本，以便可以使用每个应用程序的正确应用程序，而无需使用LoadFrom /等
运输建设 至于为运输版本更改该版本是否是一个好主意，它取决于您希望绑定如何为最终用户工作。您是否希望这些版本并排或就地？这两个版本之间有很多变化吗？他们打算打破一些客户吗？你是否担心它会破坏它们（或者你是否想强迫用户使用你的重要更新）？如果是，则应考虑增加程序集版本。但是，再一次，考虑到这样做太多次可能会使用过时的程序集丢弃用户的磁盘。
更改装配版本时 要将硬编码版本更改为新版本，我建议将变量设置为头文件中的版本，并将源代码中的硬编码替换为变量。然后，在构建期间运行预处理器以输入正确的版本。我建议在发货后立即更换版本，而不是之前，以便有更多时间来捕获由于更改而导致的错误。
答案 10 :(得分：1)
对于库，版本号会告诉您两个版本之间的兼容性级别，因此升级会有多困难。
错误修复版本需要保留二进制，源代码和序列化兼容性。
次要版本对不同的项目意味着不同的东西，但通常他们不需要保持源兼容性。
主要版本号可以打破所有三种形式。
我写了更多关于理由here。
答案 11 :(得分：1)
这取决于项目。下面是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