你怎么知道要使用哪个版本号？

这是我一直想知道的…

请原谅我的天真，但 – 你如何决定什么版本号来命名你的软件？

我假设，当有人创build一个应用程序/程序的“最终”版本，它是1.0版本？ – 那么当你更新它会发生什么，你怎么决定叫它1.1或1.03等等

这主要是为了开发者吗？

我最近听到了一个简单的版本控制策略，我第一次遇到Eric Elliot的中等账户 。 对于面向客户的版本号来说，它更倾向于库版本pipe理，但是它具有简单性的优点。 使用三部分的版本号，其中每个数字表示：

breaking.feature.fix

  • 打破 ：一些改变意味着代码/期望必须改变
  • function ：添加新东西，但旧的代码/期望仍然可以正常工作。
  • 修复 ：没有什么新东西，但一个错误已经修复。

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

我倾向于按照下面的重要数字加权….

wxyz（或w.xyz）

  • w – 主要版本，具有许多新function。 付费升级。 软件的第一个公开版本是1.X（预发行版本是0.X）
  • x – 重要版本，但没有突破性的新function。
  • Ÿ – 修复程序版本
  • z – 修补程序发布（修复一个紧急错误，可能只是针对一个客户端）。

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

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

  • 0.9 – 第一个公共testing版
  • 0.91 – 第二个公开testing版
  • 0.911 – 紧急testing版发布，以修复摩托罗拉68010的崩溃
  • 1.0 – 第一个公开发布
  • 1.1 – 增加了新的BlahBazfunction
  • 1.11 – 错误修复
  • 2.0 – 完全重新开发的界面。

杰夫·阿特伍德（Jeff Atwood）有一篇关于这个的博客文章 ，他主张使用date，而不是将用户与版本号混淆。 但是，他确实讨论了微软采取的方法：使用date来确定版本号。 他的职位深度不够，所以我不会在这里复制他的作品。 至于版本控制：

版本（至less在.NET中，像这样）：

1.2.3.4其中：

1是主要版本
2是次要版本
3是内部版本号
4是修订号

主要版本 – 表示一个“完整的”系统，具有任何版本的function。 通常，任何后续的“主要”版本都是重写，或者体系结构改变，或者（对于冗余原因）重大修改软件。

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

内部编号 – 通常意味着错误修复，小的修复，并且在其范围内有点微不足道。 这可能是像改变应用程序的前景和背景之间的对比度那样简单的事情。 一般来说，构build是内部的指定，如每晚构build，所以你总是有一个地方恢复到稳定。

修订号 – 表示何时发布错误修复或进行了非常小的增强。 这些通常只用于修正错误 – 不包括主要function增强作为修订 。

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

主要 – 主要编号与应用程序的重大更改有关。 这个数字也决定了与同一个“套件”中的其他应用程序的兼容性。 新版本发布时，这个数字会增加。 这通常意味着主要的架构变化已经发生。

次要 – 次要号码与新function和错误修复相关联。 无论什么时候引入新的function或者应用了一个突破性的错误修正，这个编号都会被提前，维护编号将被设置为零。

维护 – 维护编号与不间断的错误修复相关联。 只要发布只包含非中断错误修复程序，此编号将被提前。

构build – 构build编号与从中编译应用程序的颠覆变更集（版本号）相关联。 这将提供一个简单的方法将版本号与subversion中的一组精确的代码进行匹配。

开发人员对这个scheme真正感兴趣的唯一数字就是Build 。 数。 通过将版本号绑定到Subversion版本号，我们可以保证使用什么代码来创build发布的应用程序。

我认为Linux内核是一个很好的参考：

目前，Linux内核的版本号由四个数字组成，最近三个版本的长期策略发生了变化。 为了说明，假设版本号由此组成：ABC [.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。 他们是为了testing新的function和驱动程序，直到他们变得足够稳定，包括在一个稳定的版本。 这是一个偶数/奇数的版本号码scheme。 o从Linux 2.6.x系列开始，对于偶数或奇数都没有意义，在同一个内核系列中进行新function开发。 莱纳斯·托沃兹（Linus Torvalds）表示，这将成为可预见未来的典范。 

 * The C number indicates the minor revision of the kernel. In the old

三号版本scheme，在安全补丁，错误修复，新function或驱动程序在内核中实现时，这种情况发生了变化。 然而，随着新的政策，只有当新的驱动程序或function被引入才会改变; D号码处理小修正。 

 * AD number first occurred when a grave error, which required immediate

在2.6.8的NFS代码中遇到了。 但是，没有足够的其他更改来使新的小版本（本来是2.6.9）的发布合法化。 所以，2.6.8.1发布了，唯一的变化就是修正了这个错误。 2.6.11版本被采纳为新的官方版本政策。 错误修复和安全修补程序现在由第四个数字pipe理，而较大的更改仅在小修订更改（C编号）中实现。 D编号还与编译器构build内核的次数相关联，因此称为“内部版本号”。

此外，有时在版本之后还会有更多的字母，如'rc1'或'mm2'。 “rc”是指发布候选版本，表示非官方发布。 其他信件通常（但不总是）一个人的姓名缩写。 这表明了这个人的内核开发分支。 例如ck代表Con Kolivas，ac代表Alan Cox，而mm代表Andrew Morton。 有时，这些字母与内核构build的分支的主要开发区域有关，例如，wl表示无线networkingtesting版本。

从http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

无论您select哪种编号scheme， 在新版本与旧客户端代码兼容时，与新版本需要对现有客户端进行更改时，向用户说明是至关重要的。 当客户端代码必须改变时，我知道的大多数项目碰到了第一个数字。

除了兼容性，我也认为使用date有很多要说的。 如果像我一样，每两年发布一次（但是这是1989年发布的工具），那么它就会变得尴尬。

A B C D

  • 答：0时β，1时第一次释放，大于1几乎整个重写。
  • B：添加了新function
  • C：修正了一些错误
  • 版本控制库的版本号

这是我在embedded式C项目中使用的模块：

1.00 – 初始版本

1.01 – 小修订
没有界面更改模块（即头文件没有改变）。 任何人使用我的模块可以升级，而不必害怕破坏代码。 我可能做了一些重构或代码清理。

2.00 – 重大修订
模块接口改变（即function增加，删除或某些function改变）。 升级到这个版本很可能会破坏现有的代码，并需要使用这个模块重构代码。

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

为了增加上面的所有解释，我会build议使用一个版本控制scheme，这个scheme对于客户来说很容易记住，而且容易对你的软件版本进行基线和pipe理。 此外，如果您支持不同的框架，如.Net 1.0，.Net1.1等，那么确保您的版本控制scheme也照顾。

销售或市场营销中的某些人可能会决定他们需要一些嗡嗡声。 这将决定下一个版本是1.01还是1.1或2.0。 开源的工作方式也是一样的，但是它往往与球队引以为豪的奇特新特性联系在一起。

一些很好的信息，以及..

何时更改文件/assembly版本

何时更改文件/assembly版本首先，文件版本和assembly版本不必相互重合。 我build议文件版本随每个版本而改变。 但是，不要为每个版本更改汇编版本，以便可以区分同一文件的两个版本之间的区别; 使用文件版本。 决定何时更改组件版本需要讨论一下构build的types：运输和非运输。

非发货版本一般而言，我build议在发货版本之间保留非发货组装版本。 这避免了由于版本不匹配导致的强烈命名的程序集加载问题。 有些人更喜欢使用发布者策略为每个构buildredirect新的程序集版本。 我build议不要这样做，但是，它不能避免所有的加载问题。 例如，如果合作伙伴x复制您的应用程序，他们可能不知道要安装发布者策略。 然后，你的应用程序将被打破，即使它在你的机器上工作得很好。

但是，如果在同一台机器上的不同应用程序需要绑定到不同版本的程序集，我build议给这些版本不同的程序集版本，以便每个应用程序都可以使用正确的程序，而无需使用LoadFrom / etc。

发货版本至于是否更改发行版本的版本是一个好主意，取决于您希望绑定如何为最终用户工作。 你想要这些构build是并排还是就地？ 这两个版本之间有很多变化吗？ 他们会打破一些客户？ 你是否在乎它打破了他们（或者你想强迫用户使用你的重要更新）？ 如果是的话，你应该考虑递增程序集版本。 但是，再次，考虑到这样做太多次可以抛弃用户的磁盘与过时的程序集。

当您更改组装版本时要将硬编码版本更改为新版本，build议在头文件中将版本设置为variables，并用variablesreplace源代码中的硬编码。 然后，在构build过程中运行一个预处理器来input正确的版本。 我build议在发货后立即更改版本，而不是之前的版本，以便有更多的时间来修复由于更改而引起的错误。

在库的情况下，版本号会告诉您两个版本之间的兼容性级别 ，因此升级将有多困难。

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

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

主版本号可以打破所有三种forms。

我在这里写了更多关于这个理由的文章。

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