你怎么知道使用什么版本号？

Question

这是我一直想知道的......

请原谅我的天真，但是 - 您如何确定用于命名软件的版本号？

我假设，当有人创建应用程序/程序的“最终”版本时，它是版本1.0？ - 然后，当你更新它时会发生什么，你如何决定称它为1.1或1.03等等。

这主要是针对开发人员的吗？

Answer 1

我最近听说过我在Eric Elliot's Medium account遇到的一个简单的版本控制策略。对于面向客户版本号的库版本更加重视，但它具有简单的优势。使用三部分版本号，其中每个数字表示：

<强> breaking.feature.fix

• 打破：有些事情发生了变化，这意味着代码/期望必须改变
• 功能：添加了新内容，但旧代码/期望仍然可以正常使用。
• 修复：没什么新内容，但修复了一个错误。

我在下面留下我的旧答案，因为它仍然与面向客户的版本相关。

---

我倾向于对有效数字进行加权，如下所示....

w.x.y.z（或w.xyz）

• w - 主要版本，有许多新版本 特征。付费升级。首先 公开发布的软件是1.X （预发布版本为0.X）
• x - 重大释放，但没有 突破性的新功能。
• y - 修正版发布
• z - Patchlevel 发布（修复紧急bug， 也许只是为了一个客户）。

如果您选择使用w.xyz格式，则溢出前只能获得9位数字。但是，如果你经常发布，那么你可能会遇到更大的问题。

让我们用我的新产品FooApp来说明！

• 0.9 - 第一个公开测试版
• 0.91 - 第二个公开测试版
• 0.911 - 用于修复摩托罗拉68010崩溃的紧急测试版本
• 1.0 - 首次公开发布
• 1.1 - 添加了新的BlahBaz功能
• 1.11 - 错误修正
• 2.0 - 完全重新开发的界面。

Answer 2

杰夫阿特伍德有一个blog post关于这一点，他提倡只使用日期，而不是将用户与版本号混淆。但是，他确实讨论了Microsoft采取的方法：使用日期来确定版本号。他在帖子中进入了相当深度，所以我不会在这里复制他的作品。至于版本控制：

版本（至少在.NET中，就是这样）：

1.2.3.4其中：

1是主要版本
2是次要版本
3是构建号码
4是修订号码

主要版本 - 表示具有该版本所具有的任何功能的“完整”系统。通常，任何后续的“主要”版本都是重写，或架构更改，或（原谅冗余）软件的主要更改。

次要版本 - 表示不太重要的版本，可能有错误修复，添加了小功能或任何其他“次要”事件。这可能包括界面更改和添加。通常应用程序应该在它们的“主要版本”树中有些兼容，因此同一主要版本的次要版本在架构上应该是相同的。

内部版本号 - 通常只表示错误修复，小修复，并且在其范围内有些微不足道。它可以像改变应用程序的前景和背景之间的对比一样简单。通常，构建是内部指定，例如每晚构建，因此您总是有一个地方可以恢复到稳定。

修订号 - 表示何时发布错误修复或进行了非常小的改进。这些通常仅用于修复错误 - 不包括主要功能增强功能作为修订。

Answer 3

我们为任何应用程序的每个版本分配唯一的四部分版本号，定义为 Major.Minor.Maintenance.Build 。

专业 - 主要编号与应用程序的重大更改相关联。此数字还确定与同一“套件”中的其他应用程序的兼容性。新版本发布时，此数字会递增。这通常意味着发生了重大的架构变化。

次要 - 次要号码与新功能相关联并修复错误修复。无论何时引入新功能或应用破解错误修复，此数字都将提前，维护编号将设置为零。

维护 - 维护号与不间断的错误修复相关联。只要发布的版本仅包含非中断错误修复，该数字就会被提前。

构建 - 构建号与编译应用程序的subversion变更集（修订号）相关联。这将提供一种简单的方法，将版本号与subversion中的一组精确代码进行匹配。

开发人员对此方案真正感兴趣的唯一数字是构建。数。通过将构建编号绑定到subversion版本号，我们可以保证使用了哪些代码来创建已发布的应用程序。

Answer 4

我认为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

Answer 5

无论您选择哪种编号方案，当新版本与旧客户端代码兼容时，向新用户明确要求更改现有客户端时，向用户明确至关重要 STRONG>。我知道的大多数项目都会在客户代码发生变化时碰到第一个数字。

除了兼容性之外，我也认为使用日期有很多话要说。如果和我一样，你的发布计划是每两年一次（但这是1989年首次发布的工具），那会很尴尬。

Answer 6

销售或营销方面的某些人很可能会认为他们需要一些嗡嗡声。这将确定下一个版本是1.01还是1.1或2.0。开源中的工作方式相同，但它往往与团队引以为豪的新功能相关联。

Answer 7

A.B.C.D

• A：0时β，1时首次发布，大于1几乎全部重写。
• B：添加了新功能
• C：已完成错误修复
• 版本控制存储库的修订号

Answer 8

这是我在嵌入式C项目中用于模块的内容：

1.00 - 初始版本

1.01 - 次要修订版 没有接口改变模块（即头文件没有改变）。 使用我的模块的任何人都可以升级，而不必害怕破坏代码。 我可能已经做了一些重构或代码清理。

2.00 - 重大修订 模块接口已更改（即添加，删除功能或更改某些功能的功能）。升级到此修订版很可能会破坏现有代码，并且需要使用此模块重构代码。

我应该补充一点，这指的是开发阶段，即模块内部发布到项目中。

Answer 9

为了添加上述所有解释，我建议使用版本控制方案，让您的客户能够轻松记住并轻松地进行基线和管理软件版本。此外，如果您支持不同的框架，如.Net 1.0，.Net1.1等，那么请确保您的版本控制方案也照顾它。

Answer 10

一些好的信息here以及......

When to Change File/Assembly Versions

何时更改文件/程序集版本 首先，文件版本和汇编版本不需要相互重合。我建议每个版本都会更改文件版本。但是，不要只为每个构建更改程序集版本，以便您可以区分同一文件的两个版本;使用文件版本。决定何时更改程序集版本需要考虑要考虑的构建类型：运输和非运输。

非运输建筑 通常，我建议在运输版本之间保持非运输组件版本相同。这避免了由于版本不匹配而导致强烈命名的程序集加载问题。有些人更喜欢使用发布者策略来重定向每个构建的新程序集版本。但是，对于非运输版本，我建议不要这样做：它不能避免所有加载问题。例如，如果合作伙伴对您的应用进行x复制，则他们可能不知道安装发布商政策。然后，即使它在您的计算机上运行正常，您的应用也会被破坏。

但是，如果有同一台机器上的不同应用程序需要绑定到程序集的不同版本，我建议为这些版本提供不同的程序集版本，以便可以使用每个应用程序的正确应用程序，而无需使用LoadFrom /等

运输建设 至于为运输版本更改该版本是否是一个好主意，它取决于您希望绑定如何为最终用户工作。您是否希望这些版本并排或就地？这两个版本之间有很多变化吗？他们打算打破一些客户吗？你是否担心它会破坏它们（或者你是否想强迫用户使用你的重要更新）？如果是，则应考虑增加程序集版本。但是，再一次，考虑到这样做太多次可能会使用过时的程序集丢弃用户的磁盘。

更改装配版本时 要将硬编码版本更改为新版本，我建议将变量设置为头文件中的版本，并将源代码中的硬编码替换为变量。然后，在构建期间运行预处理器以输入正确的版本。我建议在发货后立即更换版本，而不是之前，以便有更多时间来捕获由于更改而导致的错误。

Answer 11

对于库，版本号会告诉您两个版本之间的兼容性级别，因此升级会有多困难。

错误修复版本需要保留二进制，源代码和序列化兼容性。

次要版本对不同的项目意味着不同的东西，但通常他们不需要保持源兼容性。

主要版本号可以打破所有三种形式。

我写了更多关于理由here。

Answer 12

这取决于项目。下面是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