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

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

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

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

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

我最近听过一个简单的版本控制策略,这是我第一次在Eric Elliot的Medium帐户中遇到的.对于面向客户的版本号的库版本更加重视,但它具有简单的优点.使用三部分版本号,其中每个数字表示:

breaking.feature.fix

打破:有些东西改变了,这意味着代码/期望必须改变

功能:添加了一些新内容,但旧代码/期望仍然可以正常工作.

修复:没有什么是新的,但修复了一个错误.

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

我倾向于将有效数字加权如下....

wxyz(或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 - 完全重新开发的界面.

杰夫阿特伍德有一篇关于此的博客文章,他主张只使用日期,而不是将用户与版本号混淆.但是,他确实讨论了Microsoft采取的方法:使用日期来确定版本号.他在帖子中进入了相当深度,所以我不会在这里重复他的工作.至于版本控制:

版本(至少在.NET中,就像这样):

1.2.3.4其中:

1是主要版本
2是次要版本
3是版本号
4是版本号

主要版本 - 表示具有该版本所具有的任何功能的"完整"系统.通常,任何后续的"主要"版本都是重写,或体系结构更改,或(原谅冗余)软件的主要更改.

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

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

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

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

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

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

维护 - 维护号与不间断的错误修复相关联.每当发布仅包含非中断错误修复的发布时,此数字将被提前.

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

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

我认为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.它们用于测试新功能和驱动程序,直到它们变得足够稳定以包含在稳定版本中.这是一个偶数/奇数版本号码方案.o从Linux 2.6.x系列开始,对偶数或奇数没有意义,在同一内核系列中进行新的功能开发.Linus Torvalds表示,这将是可预见的未来的典范.

* 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中,这被采纳为新的官方版本控制策略.错误修复和安全补丁现在由第四个数字管理,而更大的更改仅在次要修订更改(C编号)中实现.D编号还与编译器构建内核的次数相关联,因此称为"内部编号".

此外,有时在版本之后会有更多的字母,例如'rc1'或'mm2'.'rc'指的是候选版本,表示非正式版本.其他字母通常(但不总是)是一个人的首字母.这表明该人的内核的开发分支.例如,ck代表Con Kolivas,ac代表Alan Cox,而mm代表Andrew Morton.有时,字母与内核构建的分支的主要开发区域相关,例如,wl表示无线网络测试构建.

来自http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering