天地无用 - 软件版本号的定义

关于软件版本号的说明

软件版本管理是为计算机软件的独特状态分配独特的版本名称或独特的版本号的过程。在一个给定的版本号类别中（例如，主要或次要），这些数字通常以递增的顺序分配，并对应于软件的不断开发。在一个精细的层面上，版本控制被用来跟踪不同版本的信息，无论这些信息是否是计算机软件，以便能够回滚任何变化。

现代计算机软件通常使用两种不同的软件版本计划进行跟踪：一种是内部版本号，在一天内可能会递增很多次，如修订控制号；另一种是发布版本，通常变化频率要低得多，如符合语义标准的版本号或项目代码名称。

文件编号特别是在公共管理部门以及公司中使用，以唯一地识别文件或案例。对于计算机文件来说，这种做法在麻省理工学院的ITS文件系统中首次被引入，后来在1972年为PDP-10开发了TENEX文件系统。

后来又增加了文件清单，包括它们的版本，以及它们之间的依赖关系。像Debian这样的Linux发行版，其中的dpkg，很早就创建了软件包管理软件，可以解决其软件包之间的依赖关系。Debian的第一次尝试是，一个软件包知道其他依赖它的软件包。从1994年开始，这个想法反转了，是一个软件包知道它所需要的软件包。当安装一个软件包时，通过依赖关系解析来自动计算出所需的软件包，并将它们与所需的软件包一起安装。为了有利于软件升级，希望引入最小的软件包版本变化。因此，编号方案需要能够判断出哪个是最新的并且符合需要的版本。

基于一组序列的方案中(a sequence-based software versioning schemes)，每个软件版本都被分配了一个唯一的标识符，该标识符由一个或多个数字或字母序列组成。但不同方案在诸如序列的数量、单个序列的意义以及序列递增的方式等方面有很大不同。

在一些方案中，基于序列的标识符被用来表达不同版本之间变化的重要性(significance)。变更是按重要性等级分类的，决定在不同版本之间改变哪个序列是相对于前一个版本的变更的重要性，因此第一个序列被改变为最重要的变更，而第一个序列之后的变更代表重要性的降低。

根据不同的方案，重要性可以通过以下各方面来衡量：改变的代码行数、增加或删除的功能点、对客户的潜在影响(为采用新版本所需的工作)、bug或未宣布的破坏性变化的风险、视觉布局的变化程度、新功能的数量，或几乎任何产品开发者或营销人员认为重要的东西来评估，包括强调新版本 "比前一版本更好 "的营销愿望。

具体定义

一般的版本号定义，是一个major number，一个minor number，后面可以跟相应的信息编码，比如构建编号、修订编号(Source Control System里的编号)、发布编号、时间戳、补丁号、安全问题修复号或自定义的编号（build, revision, release, datestamp, hotfix, security fix, to any custom algorithms）。比如.Net 4.0的版本定义就是Major.Minor.Build.Revision，Delphi里就是Major.Minor.Release.Build。

在 C# AssemblyInfo.cs文件中，相关定义是这样的：

// Version information for an assembly consists of the following four values:

//

//      Major Version

//      Minor Version

//      Build Number

//      Revision

//

/ You can specify all the values or you can default the Build and Revision Numbers

// by using the '*' as shown below:

// [assembly: AssemblyVersion("1.0.*")]

最常用的版本号编制格式是：

x.y.z（major.minor.build）

x是主版本号，代表主要功能、接口或界面的变化，应用框架(application stack)的架构更改，平台基础构件(platform infrastructure)的修改，或对外的网络接口(exposed network interface)变更，这些变化可能会影响兼容性；

y表示小版本号，小功能(feature)变化，小的优化(improvement)（如局部架构变化），bug修复，或者内部更新(internally update)，一般的UI调整，组件添加或更新，API变更；同一产品的不同组件(components)，如果小版本号不同，可能无法者不应协同工作；

z是构建编号（build number），一般在软件的”关于“窗口里可以看到，用来在客户支持中提供细节信息。这个是自由格式，每个产品可以分别定义。可以是每日加1，或者每次发布版本加1，或者每次构建加1。Build number也可以作为Pre-release number，这个数字不断变化，当达到一定程度，就会触发一个新的minor version release。

当软件的版本号发生变化，对其包含的组件来说，要么保持不变，要么增加版本号。可以所有组件共享一个版本号，也可以仅仅增加发生变化的组件的版本号。

如果是带数据库的软件的话：

1，第一个数字表示整个系统的版本，一般若干年才改一次，通常代表技术上的根本变化，或客户用的功能，或两者都有。

2，第二个数字表示数据库模型的修订版本。这个数字增加后需要进行数据库迁移，所以是一个重大的变化，可能需要系统备份，所以改变数据库结构需要一个谨慎的升级过程。如果第一个数字发生变化，则重设为0。

3，第三个数字表示纯软件上的变更。这通常可以由客户在客户端来操作，因为数据库结构没有变化。如果第二个数字发生变化，则重设为0。

4，Subversion的版本号。比如使用TortoiseSVN工具在构建时自动填充这个数字。这个数字永远不会重置，而是不断地增加。使用这个数字，可以随时重新创建任何版本。

如果你不需要跟踪数据库的修订，可以只需要使用3位或2位的版本号，那会更简单一些。(这个就类似build编号，可以根据情况来决定这个编号的信息格式)

1. First number = Overall system era. Changes every couple of years and typically represents a fundamental change in technology, or client features or both.

2. Second number = database schema revision. An increment in this number requires a database migration and so is a significant change (or systems replicate and so changing the database structure requires a careful upgrade process). Resets to 0 if the first number changes.

3. Third number = software only change. This can usually be implemented on a client by client basis as the database schema is unchanged. Resets to zero if the second number changes.

4. Subversion version number. We populate this automatically on build using the TortoiseSVN tool. This number never resets but continually increments. Using this we can always recreate any version.

This system is serving us well because every number has a clear and important function. I have seen other teams grappling with the major number/minor number question (how big a change is major) and I dont see the benefit to that. If you dont need to track database revisions just go to a 3 or 2 digit version number, and make life easier!

版本号定义的规范(Semantic versioning)

有一个语义化版本号规范：Semantic Versioning [semver2.0]，网址：Semantic Versioning 2.0.0 | Semantic Versioning 。

Semantic versioning（又称SemVer）是一种被广泛采用的版本方案，它通过三部分版本号（Major.Minor.Patch）、一个可选的预发布标签(pre-release tag)和一个可选的构建元标签(optional build meta tag)来编码版本。在这个方案中，风险和功能是衡量软件变化影响大小的标准。破坏性的变化通过增加主版本号来表示（高风险）；新的、非破坏性的功能会增加次版本号（中等风险）；所有其他非破坏性的变化会增加补丁号（最低风险）。预发布标签（-alpha，-beta）的存在表明有很大的风险，主要版本号为零（0.y.z）也是如此，它被用来表示一个正在开发中的工作，可能包含任何程度的潜在破坏性变化（最高风险）。作为从SemVer版本推断兼容性的一个例子，依赖2.1.5版API的软件与2.2.3版兼容，但不一定与3.2.4版兼容。

开发者可能会选择一次跳过多个次要版本，以表明增加了重要的功能，但不足以保证增加主要版本号；例如，Internet Explorer 5从5.1到5.5或Adobe Photoshop 5到5.5。这样做可能是为了强调升级对软件用户的价值，或者像Adobe的情况一样，代表主要版本之间的一个版本（尽管基于序列的版本划分水平不一定限于一个数字，如Blender 2.91版或Minecraft Java版从1.7.10开始）。

一种不同的方法是使用主要数字和次要数字以及表示发布类型的字母数字字符串，例如 "alpha"（a）、"beta"（b）或 "候选发布"（rc）。使用这种方法的软件发布列车可能看起来像0.5、0.6、0.7、0.8、0.9→1.0b1、1.0b2（有一些修正）、1.0b3（有更多的修正）→1.0rc1（如果它足够稳定）、1.0rc2（如果发现更多的bug）→1.0。在这个计划中，常见的做法是在候选版本阶段锁定新的功能和破坏性的变化，对于一些团队来说，甚至连测试版也被锁定为只允许修复错误，以确保和最终版本的一致性。

其他方案则对个别序列赋予了意义：

major.minor[.build[.revision]] (例如：1.2.12.102)

major.minor[.maintain[.build]] （例如：1.4.3.5249）。

同样，在这些例子中，什么是 "主要 "与 "次要 "变化的定义完全是主观的，由作者决定，正如什么是 "构建 "的定义，或者 "修订 "与 "次要 "变化的区别。

Solaris和Linux的共享库可以使用current.revision.age格式，其中：

current：该库实现的最新的接口号。

revision： 当前接口的实现编号。

age： 该库实现的最新和最老的接口之间的差异。第三个字段的这种用法是libtool所特有的：其他的可能使用不同的含义，或者干脆忽略它。

在图书出版中也存在类似的相对变化意义和版本命名的问题，版本号或名称可以根据不同的标准来选择。

在大多数专有软件中，软件产品的第一个发布版本是版本1。

兼容性（Degree of compatibility）

一些项目使用主要版本号来表示不兼容的版本。两个例子是Apache Portable Runtime（APR）和FarCry CMS。

通常情况下，程序员编写的新软件是向后兼容的，也就是说，新软件被设计成可以与旧版本的软件（使用旧的协议和文件格式）和最新的版本（使用最新的协议和文件格式）正确互动。例如，IBM z/OS被设计成在同一个系统联合体中，可以正常运行3个连续的主要版本的操作系统。这使管理高可用性计算机集群的人能够在每次关闭、升级和恢复服务的一台机器时保持大部分计算机的正常运行 。

通常数据包头和文件格式包括一个版本号--有时与编写软件的版本号相同；其他时候是独立于软件版本号的 "protocol version number"。处理旧的废弃协议和文件格式的代码常常被看作是令人讨厌的东西。

指定开发阶段的版本号(Designating development stage)

处于实验阶段（alpha或beta）的软件通常在序列的第一个（"主要"）位置使用0来指定其状态。然而，这种方案只对早期阶段有用，对即将发布的、版本号已经超过0的成熟软件并不适用。

有一些方案被用来表示较新版本的状态：

字母数字后缀是语义版本管理所采用的一种常见方案。在这种方案中，各版本都附加了一个破折号和一些字母数字字符来表示状态。

数字状态是一种使用数字来表示状态的方案，好像它是序列的一部分。一个典型的选择是四位数版本的第三位。

数字式90+是另一种使用数字的方案，但显然是在前一个版本的数字下。在最后一个位置使用一个大的数字，通常是90或更高。这通常被像Fontconfig这样的老的开源项目使用。

比如要发布1.2版本时，那预发布版本就是1.1.90或大一些号码。

Comparison of development stage indicators
Development	Semantic	Numeric	Numeric
stage	versioning	status	90+
Alpha	1.2.0-a.1	1.2.0.1	1.1.90
Beta	1.2.0-b.2	1.2.1.2	1.1.93
Release candidate (RC)	1.2.0-rc.3	1.2.2.3	1.1.97
Release	1.2.0	1.2.3.0	1.2.0
Post-release fixes	1.2.5	1.2.3.5	1.2.5

这两种纯粹的数字形式消除了处理 "alpha < beta < rc < no prefix "的比较所需的特殊逻辑，这在语义版本管理中是可以发现的，但代价是不那么清晰。

递增序列（Incrementing sequences）

关于数字版本号如何递增，有两派观点。大多数自由和开源软件包，包括MediaWiki，都把版本号看作是一系列单独的数字，用句号隔开，其递增方式是：1.7.0、1.8.0、1.8.1、1.9.0、1.10.0、1.11.0、1.11.1、1.11.2，以此类推。

另一方面，一些软件包通过十进制数字来识别版本： 1.7、1.8、1.81、1.82、1.9，等等。十进制版本在20世纪80年代很常见，例如NetWare、DOS和Microsoft Windows，但即使在2000年代，Opera和Movable Type也在使用。在十进制方案中，1.81是1.8之后的次要版本，而维护版本（即仅是错误修复）可以用一个字母后缀表示，例如1.81a或1.81b。

标准的GNU版本编号方案是major.minor.revision，但Emacs是一个值得注意的例子，它使用了另一种方案，主要编号被取消，并增加了一个用户网站的修订版，在原始Emacs软件包中总是0，但由分销商增加。同样，Debian软件包编号的前缀是一个可选的 "epoch"，它被用来允许改变版本方案。

重置(Resetting)

在某些情况下，开发者可能会决定重置主版本号。这有时是用来表示一个新的开发阶段正在发布。例如，Minecraft Alpha从1.0.0版本运行到1.2.6，当Beta版发布时，它重置了主要版本号，从1.0运行到1.8。一旦游戏完全发布，主要版本号再次重设为1.0.0。

序列的分隔（Separating sequences）

打印时，序列可以用字符分开。字符的选择和它们的使用因方案而异。下面的列表显示了同一版本的分离方案的假设性例子（第十三次三级修订到第四次二级修订到第二次一级修订）：

一个方案可以在所有序列之间使用相同的字符： 2.4.13, 2/4/13, 2-4-13

一个方案对分离哪些序列的选择可能是不一致的，分离一些序列而不分离其他序列：2.413

在同一个标识符中，一个方案对字符的选择可能不一致：2.4_13（例如，Minecraft Beta从1.7增加到1.7_01再到1.7.2）

当用句号来分隔序列时，它可能代表小数点，也可能不代表小数点，如果是十进制数字就不是小数点。

序列的数量(Number of sequences)

有时还有第四个未公布的数字，表示软件的构建（如微软所使用的）。Adobe Flash是一个值得注意的例子，它的四个版本号是公开表示的，如10.1.53.64。一些公司还包括构建日期。版本号也可以包括字母和其他字符，如Lotus 1-2-3 Release 1a。

负数(Negative numbers)

有些项目使用负数的版本号。一个例子是SmartEiffel编译器，它从-1.0开始，向上数到0.0。

发行日期（Date of release）

街头霸王(Street Fighter)EX的闪屏显示了CalVer格式的发行号： "961219 USA"

许多项目使用一种基于日期的版本管理方案，称为日历版本管理（Calendar Versioning ，又称CalVer）。

Ubuntu是使用日历版本管理的项目的一个例子；例如，Ubuntu 18.04是在2018年4月发布的。这有一个好处，就是很容易与开发时间表和支持时间表联系起来。一些视频游戏也使用日期作为版本标识，例如街机游戏《街头霸王EX》。在启动时，它显示的版本号是一个日期加上一个地区代码，例如961219 ASIA。

当在版本管理中使用日期时，例如，文件名，通常使用ISO 8601方案YYYY-MM-DD，因为这很容易以增加或减少的顺序进行字符串排序。连字符有时会被省略。Wine项目以前使用的是日期版本计划，它使用年份，其次是月份，然后是发布日期；例如，"Wine 20040505"。Minecraft也有类似的版本格式，但改用DDHHMM，例如：rd-132211，13是5月13日，2211是22:11。

微软Office的构建号是一个编码的日期：前两位数字表示从项目开始的那一年的1月开始的月数（每个主要的Office版本是不同的项目），而后两位数字表示该月的一天。因此，3419是指从项目开始的那一年的1月算起的第34个月的第19天。

其他以年份标识版本的例子包括Adobe Illustrator 88和WordPerfect Office 2003。当用年份来表示版本时，一般是出于营销的目的，而且也存在一个实际的版本号。例如，Windows 95的内部版本为MS-DOS 7.00和Windows 4.00；同样，Windows 2000的内部版本为NT 5.0。

其他方案

一些软件生产商使用不同的方案来表示他们的软件版本。Debian项目对其操作系统的版本使用主要/次要版本计划，但在开发过程中使用电影《玩具总动员》中的代码名称来指代稳定、不稳定和测试版本 。

BLAG Linux和GNU的特点是版本号非常大：主要版本的数字如50000和60000，而次要版本的数字增加1（如50001、50002）。α和β版本的版本号是比主要版本号小一个数字的，例如19999.00071表示20000版本的α1，29999.50000表示30000版本的β2。从2003年的9001开始，截至2011年的最新版本是140000。

Urbit使用开尔文(Kelvin)版本法（以绝对开尔文温标命名）：软件版本从一个高数字开始，倒数到0版本，在这一点上，软件被认为已经完成，不再进行任何修改。

内部版本号（Internal version numbers）

软件可能有一个 "内部 "版本号，与产品名称中显示的版本号不同（而且通常更一致地遵循版本号规则）。例如，Java SE 5.0的内部版本号为1.5.0，而从NT 4开始的Windows版本在内部继续使用标准的数字版本： Windows 2000是NT 5.0，XP是Windows NT 5.1，Windows Server 2003和Windows XP Professional x64 Edition是NT 5.2，Windows Server 2008和Vista是NT 6.0，Windows Server 2008 R2和Windows 7是NT 6.1，Windows Server 2012和Windows 8是NT 6.2，而Windows Server 2012 R2和Windows 8.1是NT 6.3，然而Windows 10的第一个版本是10.0（10.0.10240）。不过请注意，Windows NT现在只是第五次重大修订，因为它的第一个版本的编号是3.1（以配合当时的Windows版本号），而Windows 10的推出实现了从6.3到10.0的版本飞跃。

预发布版本（Pre-release versions）

结合上面列出的各种版本计划，通常会使用一个表示预发布版本的系统，用来管理软件发布周期的各个阶段。

处于早期阶段的程序通常被称为 "alpha "软件，以希腊字母表的第一个字母命名。在它们成熟但还没有准备好发布之后，它们可能被称为 "beta "软件，以希腊字母中的第二个字母命名。一般来说，阿尔法软件只由开发者测试，而贝塔软件则是为社区测试而分发。

一些系统使用小于1的数字版本（如0.9），以表明他们接近最终的 "1.0 "版本。这是开放源码软件的一个常见惯例。然而，如果预发布版本是一个现有的软件包（例如2.5版本），那么可以在版本号后面加上一个 "a "或 "alpha"。因此，2.5版本的alpha版本可以被识别为2.5a或2.5.a。

另一种方法是将预发布的版本称为 "候选版本(release candidates)"，这样一来，即将作为特定版本发布的软件包就可以在该版本标签后面加上 "rc-#"，表示候选版本的编号；当最终版本发布时，"rc "标签就会被删除。

发布列车（release train）

软件发布列车是一种软件发布计划的形式，在这种计划中，多个产品的不同系列的版本软件被作为若干不同的 "列车 "定期发布。一般来说，对于每个产品系列，在给定的时间内都有一些不同的发布列车在运行，每个列车在计划的时间内从最初的发布到最终的成熟和退出。用户可以在生产中采用较新的发布列车之前进行试验，允许他们在早期试验较新的、"原始 "的发布，同时在他们的生产系统中继续遵循前一列车的发布，然后在新的发布列车变得成熟时转向该列车。

思科的IOS软件平台多年来使用了一个有许多不同列车的发布时间表。最近，包括Firefox和Fenix for Android、 Eclipse、LibreOffice、Ubuntu、Fedora、Python、digiKam 和 VMware在内的许多其他平台都采用了发布列车模式。

有的厂商抛弃了主版本号(Dropping the most significant element)

Sun公司的Java有时也有一个hybrid系统，内部版本号一直是1.x，但在市场上只提到了x：

JDK 1.0.3

JDK 1.1.2 到 1.1.8

J2SE 1.2.0（"Java 2"）到1.4.2

Java 1.5.0, 1.6.0, 1.7.0, 1.8.0（"Java 5, 6, 7, 8"）。

Sun也放弃了Solaris的第一个数字，Solaris 2.8（或2.9）在营销材料中被称为Solaris 8（或9）。

2010年代初，Asterisk开源PBX构建套件也发生了类似的跳跃，其项目负责人宣布，目前的1.8.x版本很快就会出现10版本 。

这种做法被许多人所诟病，因为它打破了版本号各部分的语义意义，但却被越来越多的厂商所采用，包括Mozilla（针对Firefox）。

版本号的奇偶问题（Odd&Even numbered versions）

在1.0和2.6.x系列之间，Linux内核使用奇数次要版本号表示开发版本，偶数次要版本号表示稳定版本；见Linux内核§版本编号。例如，Linux 2.3是Linux内核第二个主要设计的开发系列，而Linux 2.4是Linux 2.3成熟后的稳定发布系列。在Linux内核的次要版本号之后是发行号，按升序排列；例如，Linux 2.4.0 → Linux 2.4.22。自从2004年2.6内核发布后，Linux不再使用这个系统，而是采用了更短的发布周期。

其他一些发布周期较长的软件也使用了同样的奇偶系统，比如Node.js直到0.12版本之前，以及GNOME和WineHQ。

版本号的排序问题(Version number ordering systems)

版本号很快就从简单的整数（1，2，......）发展到有理数（2.08，2.09，2.10），然后是非数字的 "数字"，如4：3.4.3-2，因此这些复杂的版本号最好作为字符串处理。包含软件包管理设施的操作系统（如所有非琐碎的Linux或BSD发行版）将使用一个特定的发行版算法来比较不同软件包的版本号。例如，Red Hat和衍生发行版的排序算法与类似Debian的发行版不同。

作为一个令人惊讶的版本号排序实施行为的例子，在Debian中，前导零被忽略，所以5.0005和5.5被认为是相等的，而5.5<5.0006。这可能会使用户感到困惑；字符串匹配工具可能无法找到给定的版本号；如果程序员使用字符串索引的数据结构，如版本号索引的哈希表，这可能会在软件包管理中造成微妙的错误。

为了便于分类，一些软件包用固定的宽度来表示major.minor.release方案的每个组成部分。Perl把它的版本号表示为一个浮点数；例如，Perl的5.8.7版本也可以表示为5.008007。这样，理论上5.8.10的版本就可以表示为5.008010。其他软件包将每个段打包成一个固定的位宽；例如，在微软的Windows上，版本号6.3.9600.16384可以表示为十六进制的0x0006000325804000。如果版本号的任何一段超过999，浮点方案就会失效；采用每段16位的二进制打包方案在65535之后就会失效。

版本号使用举例Python

Python 软件基金会发布了 PEP 440 - 版本识别和依赖性规范，概述了他们自己的灵活方案，其中定义了一个纪元段（epoch segment）、一个发布段(release segment)、发布前(pre-release)和发布后段(post-release)以及一个开发版段(development release segment)。

版本号使用举例TeX

TeX有一个特殊的版本编号系统，这是其开发者Donald Knuth发明的一个不寻常的功能。从第3版开始，更新是通过在末尾增加一个额外的数字来表示的，这样版本号就渐渐接近数字π；这是一种单数编号的形式--版本号就是数字的数量。目前的版本是3.141592653。这反映了TeX是非常稳定的，预计只有小的更新。TeX的开发者Donald Knuth曾说过，绝对的最后改动将是把版本号改为π，届时所有剩余的bug都将成为永久性的特性。

类似地，Metafont的版本号渐进地接近欧拉数e（2.72...，自然对数的基数）。目前Metafont的版本号是2.71828182。Metafont也是由Donald Knuth设计的，作为他的TeX排版系统的伴侣。

版本号使用举例苹果公司

在经典的Mac OS时代，次要版本号很少后面再加".1"。因此，"8.5 "被当作自己的版本进行销售，代表 "Mac OS 8.5"，而8.6实际上意味着 "8.5.1"。

Mac OS X偏离了这一趋势，很大程度上是因为 "X"（10的罗马数字）出现在产品的名称中。因此，OS X的所有版本都以数字10开始。OS X的第一个主要版本被赋予了10.0的版本号，但下一个主要版本不是11.0。相反，它被编号为10.1，然后是10.2、10.3，以此类推，每个后续的主要版本。因此，OS X的第11个主要版本被标记为 "10.10"。尽管从macOS 10.12开始，"X "被从名称中删除，但这种编号方案一直持续到macOS 10.15。在基于 "X "的版本计划下，第三个数字（而不是第二个）表示一个次要版本，和低于这个级别的额外更新，以及在新的主要版本发布后对OS X的特定主要版本的更新，被称为补充更新。

罗马数字X同时被用于多个产品系列的营销目的。QuickTime和Final Cut Pro都从7版直接跳到了10版，即QuickTime X和Final Cut Pro X。与Mac OS X本身一样，这些产品不是以前版本的升级版，而是全新的程序。与OS X一样，这些程序的主要版本增加了第二位数字，次要版本则使用第三位数字表示。随着macOS 11.0的发布，Final Cut名称中的 "X "被取消了（见下文），而当QuickTime框架在2011年被弃用而改用AVFoundation时，QuickTime的品牌也变得毫无意义（播放QuickTime视频的程序从一开始就只被称为QuickTime Player）。

苹果的下一个macOS版本，暂时编号为10.16， 在2020年6月的WWDC上正式宣布为macOS 11，并在2020年11月发布。接下来的macOS版本，macOS Monterey，在2021年10月发布，将其主要版本号提升到12。

版本号使用举例Microsoft Windows

微软视窗操作系统最初是用标准的版本号来标示Windows 1.0到Windows 3.11。在这之后，微软将版本号从产品名称中排除。对于Windows 95（4.0版）、Windows 98（4.10版）和Windows 2000（5.0版），产品名称中包含了发布年份。在Windows 2000之后，微软创建了Windows服务器系列，该系列延续了基于年份的风格，但有一点不同： 对于次要版本，微软在标题中添加了 "R2"，例如，Windows Server 2008 R2（6.1版本）。这种风格一直保持到现在。然而，Windows的客户端版本并没有采用一致的风格。首先，它们收到了带有任意字母数字后缀的名称，如Windows Me（4.90）、Windows XP（5.1）和Windows Vista（6.0）。然后，微软再次在标题中采用了增量数字，但这一次，它们不是版本号；Windows 7、Windows 8和Windows 8.1的版本号分别是6.1、6.2和6.3。在Windows 10中，版本号跃升至10.0，而操作系统的后续更新只增加了构建号和更新构建修订（update build revision - UBR）号。

Windows 10的继任者，Windows 11，于2021年10月5日发布。尽管被命名为 "11"，新的Windows版本并没有将其主要版本号提升到11。相反，它保持了Windows 10所使用的10.0版本号。

软件发布版本号的意义(Significance)：

在软件工程的实际应用中，版本号被消费者或客户用来识别或比较他们的软件产品副本与另一个副本，如开发者发布的最新版本。对于程序员或公司来说，版本号通常是在基于软件的不断修改而变化，包括软件的各个独立组成部分，通常是包含在一个版本控制系统中。

软件版本编制的策略对于软件库和框架尤其重要，但是对于命令行应用程序（可能被其他应用程序调用）以及实际上任何其他应用程序（可以为其编制脚本，或者由第三方来扩展）来说，也可能非常有用。

为了实现许多软件的修补和升级计划(patching and upgrading scheme)，版本管理也是一种必要的做法，特别是自动决定要如何升级。

版本号使提供支持的人能够准确地确定用户正在运行的代码，这样他们就可以排除已经被修复的错误是造成问题的原因，及类似情况。当一个程序有大量的用户群体时，这一点尤其重要，特别是当这个群体大到提供技术支持的人不是编写代码的人时。version.revision.change这种风格编号的语义对信息技术人员也很重要，他们经常用它来确定在将新版本部署到他们的设施中之前，他们需要对其给予多大的关注和研究。作为一个经验法则（a rule of thumb），版本号变化越大，可能出现故障的可能性就越大（尽管检查了Changelog，可能只发现表面的或不相关 superficial or irrelevant的变化）。这也是Asterisk等公司采取的 "放弃主要版本 "的做法所引起的一些反感的原因之一：因为工作人员必须（或至少应该）为每一次更新做全面的回归测试。

比如如果发布的软件是一个单纯的库，那使用版本号对比可以表示出兼容性的级别（level of compatibility），以及进行升级的影响有多大。

小的bug修改，就应该保留二进制格式、源代码和序列化的兼容（A bug fix release needs to preserve binary, source, and serialization compatibility）。

而次要版本号的变化，对于不同的项目会有不同的意义，但通常代表是一次源代码的里程碑，可以视为源码不兼容。

而主要版本变化，会有更大的变化，意味着binary、source和serialization的兼容性都可能被破坏。

一些售卖的软件，其售后支持的时间可能是有限的，或者在有限的版本范围内。比如仅对相同主版本号软件进行支持。如果需要增加支持范围，需要新的售卖合同。

用户购买软件后，软件需要升级的话，根据合同，也可能是在有限时间内，或者有限的版本范围内。就是说，购买软件后，对于后续服务，是和版本变化有关的，根据版本号的变化，影响了用户的权益。

而产品投放市场后， 可能使用不同的版本号编制规则(marketing versioning scheme)，那就是版本号越大越好，大的号比小的号好，最好还要比竞争对手的大。

比如苹果手机的版本更新一代，就是版本号加一，识别起来很方便。版本号越大就越新越好，比如iphone 14就比iphone 13好。

而且苹果在设计新一代手机时，还尽量在外观上做出区分，让别人知道你用的是最新款手机，刺激了人们的购买欲望。

后来小米手机的版本定义，也使用了类似的规则，比如小米13手机。

除了数字类型信息的编号，还有一些用特殊名字来更人性化的表达来区分版本的。比如，Max OS的版本：从Cheetah(猎豹)到Ventura(加州一个城市的名字)。

参见：

Find out which macOS your Mac is using - Apple Support

https://en.wikipedia.org/wiki/MacOS

在非软件领域的版本号编制应用

在一些文件系统中，也会给文件进行版本编号。文件中的版本号与计算机和软件工程中使用的套路比较类似，当结构、内容或条件的发生变化，版本号都会增加1，加哪个版本号取决于作者的个人偏好和所做变化的大小或重要性。

===分割线===

一些具有政治或文化意义的版本号

一般major版本0表示开发版本，意味着软件不完整或者还不能稳定使用，而且这时的版本可能无法向后兼容。version 1.0是一个正式开始发布的里程碑，表示软件至少有了所有的主要特性和开发人员希望在该版本中实现的功能，并被认为足够可靠并正常发布。一个很好的例子是Linux内核，它在1991年首次发布为0.01版本，直到1994年才达到1.0.0版本。

街机游戏模拟器MAME的开发者不打算发布该程序的1.0版本，因为总会有更多的街机游戏需要模拟，因此该项目不可能真正完成。因此，0.99版之后是0.100版。

自从互联网普及以来，大多数商业软件供应商不再遵循一个主要版本应该是完成状态(complete)的格言，而是依靠带有错误修复的补丁来处理出现的问题，这些问题已被发现，已有解决方案，可以被修复。

出于营销的原因，一个相对普遍的做法是，在版本号上进行重大的跳跃。有时，软件供应商会绕过1.0版本，或者迅速发布一个带有后续版本号的版本，因为许多客户认为1.0版本的软件太不成熟，不值得在生产部署中信任。例如，以dBase II为例，推出这个产品时的版本号就是II，其版本号意味着它更成熟。

另一些时候，版本号被提高，以配合竞争对手的版本。这可以从微软、美国在线、Sun Solaris、Java虚拟机、SCO Unix、WordPerfect的许多产品版本号的例子中看到。微软Access从2.0版本跳到7.0版本，以配合微软Word的版本号。

微软的版本号也是别人追赶的目标，网景浏览器从5版跳到6版，与微软的IE浏览器保持一致，但也是因为Mozilla应用套件在1.0之前的开发过程中在其用户代理字符串中继承了5版，而网景6.x是建立在Mozilla的代码基础上。

另一个跟上竞争对手的例子是Slackware Linux在1999年从第4版跳到了第7版。

版本号有时也受到迷信(Superstition)的影响。微软Office 2007版本的内部版本号为12。下一个版本Office 2010的内部版本为14，这是因为围绕数字13的迷信。 Visual Studio 2013的产品版本号为12.0，而新版本Visual Studio 2015的版本号为14.0，原因相同。

Roxio Toast从12版到14版，很可能是为了跳过围绕数字13的迷信。

Corel公司的WordPerfect Office，第13版在市场上被称为 "X3"（罗马数字10和 "3"）。这一程序一直延续到下一个版本，即X4。同样的情况也发生在Corel公司的图形套件（即CorelDRAW、Corel Photo-Paint）以及其视频编辑软件 "Video Studio "上。

Sybase在其Adaptive Server Enterprise关系数据库产品中跳过了主要的13和14版本，从12.5转移到15.0。

ABBYY Lingvo词典使用编号12、x3（14）、x5（15）。

SUSE Linux Enterprise在12版之后跳过了13和14版，直接在2018年7月发布了SLES 15。

还有受到极客文化(Geek culture)所影响的版本号指定。SUSE Linux发行版从4.2版本开始，以参考42，即道格拉斯-亚当斯的《银河系搭车指南》中提到的 "生命、宇宙和万物的终极问题的答案"。

一个Slackware Linux发行版的版本是13.37，参考了leet。

Finnix从93.0版本跳到100版本，部分原因是为了实现 "不会有Finnix '95 "的断言，这是对Windows 95的引用。

===分割线===

版本发布分三类major、minor和emergency。

主要版本发布

主要版本变更通常会推翻软件的先前版本。

一个主要版本发布拥有大量的产品变化，并在功能上进行了关键的改进。例如，一个主要的版本发布可能包括：

• 代码重写提供更好的性能和扩展性

• 用户界面的改变，使之具有全新的外观和感觉

• 改变使用方式的新功能发布

• 移除过时的或废弃的功能

• 提供了新的软件集成

• 兼容新硬件

主要版本发布对用户来说是最具破坏性的。它们引入了新的东西，并可能需要时间和精力来下载或配置。

这意味着主要版本发布可能会让人反感，并可能需要你为你的客户提供培训，或专门花时间将数据迁移到新的版本。

它们也可能意味着兼容性方面的问题或变化。例如，新发的主要版本可能无法向后兼容旧硬件和旧程序。

因此，当你准备发布一个软件的主要版本时，一定要让你的用户了解情况。不要让他们感到惊讶，并确保你已经准备好对新版本软件进行支持。

Major version releases

They typically overrule previous releases of the software.

A major release boasts substantial product changes and rolls out key improvements in functionality. For example, a major release might include:

* A rewritten codebase offering improved speed and resilience

* User interface changes for a fresh look and feel

* Game-changing new feature releases

* The removal of outdated or dropped features

* Integrations into new software and/or compatibility for newer hardware

What major releases mean for users

Major releases are the most disruptive for users. They introduce new things and likely require time and effort to download or configure.

This means that major releases can cause change aversion. They may require you to provide training to your customers, or dedicated time for migrating data to the new version.

They may also mean issues or changes with compatibility. For instance, a major release may not be backwards-compatible with older hardware and legacy programs.

So, when you’re getting ready for a major software release, be sure to keep your users in the loop. Don’t surprise them, and ensure that you’re ready to support them onto the new version of your software.

次要版本发布

次要版本发布也被称为更新，基于主要版本进行安装。也就是说，它们对软件的当前版本进行修改。

次要版本发布比主版本发布变化要小。它们并不是对您的软件产品进行全面检修或推陈出新。相反，它们加强和改进现有的功能。

因此，一个次要版本发布可能包括：

• 有限的新特性和功能

• 对现有功能的小规模更新

• 小的错误修复和持续的安全补丁

很多软件运行时会定期检查次要版本的更新，有的还会在后台就完成版本升级。

次要版本发布对用户来说可能会造成一些干扰。但它们的影响比主要版本发布要小。

次要版本发布对软件用户来说是一种平衡策略。需要运行软件更新来升级，但更新完以后并不会使软件看起来像是新的东西。

用户仍然在使用当前版本的软件，所以几乎不需要花时间或精力去适应最新的版本。用户需要花时间学习新功能的可能性也小得多。

这种软件发布类型仍然可能意味着用户面临一些轻微的变化厌恶。例如，如果对某些UI选项进行了调整，或者他们不喜欢某个新功能。

然而，在大多数情况下，次要版本意味着体验改进上不会有太大干扰。

Minor version releases

Minor releases are also known as updates, and they’re installed on top of major releases. That is, they edit the current version of the software.

Minor software releases are smaller than their major counterpart. They are not a total overhaul or a new version of your software offering. Rather, they enhance and improve existing functions.

So, a minor release might include:

* Limited new features and functionality

* Small updates to existing features

* Minor bug fixes and ongoing security patches

Minor releases will run regularly, and often do so in the background.

What minor releases mean for users

Minor releases can represent some disruption for users. But they are less impactful than major releases.

Minor releases are a balance for software users. They can require the time it takes to run the update, but they don’t represent changes big enough to make the software seem new.

Users are still using the current version of the software, so little to no time or effort is needed to adapt to the latest release. It’s also much less likely that users will need to spend time learning new features.

This software release type can still mean that users face some minor change aversion. For instance, if there’s been a tweak to certain UI options, or they dislike a new feature.

However, for the most part, minor releases mean an improved experience for minor disruption.

紧急版本发布

紧急版本发布也被称为 "热修复"。

紧急发布是为了解决突然出现的或紧迫的问题，需要尽快修复。它们可能解决：

• 使软件的某些部分停止工作的关键错误

• 最近发现的一个高优先级的安全漏洞

紧急版本发布的意义在于它们修复了一些紧急问题。它们并不是为了极大地改善用户体验，而是为了确保软件能够继续有效和安全地运行。

紧急发布只对其直接修复的问题产生（明显的）影响。例如，X功能不再崩溃，或者Y不再是一个网络安全漏洞。

用户可能已经经历了有关错误或漏洞带来的不便或干扰。他们对你的服务的信任也可能下降了。因此，对于用户来说，紧急发布意味着事情能够恢复原样或者保持正常。

那么，一个及时的紧急发布意味着用户可以继续有效地使用该软件。而且，如果处理得迅速而得力，还可以恢复用户对该产品的信心。

Emergency software releases

You might also have heard of them as ‘hotfixes’.

Emergency releases are there for the times there’s a sudden or pressing problem that needs fixing as soon as possible. They might address:

* Critical bugs that make parts of the software stop working

* A high-priority security vulnerability that’s been recently discovered

The point of emergency releases is that they fix something urgent. They’re not there to dramatically improve the user experience, but to ensure the software continues to run effectively and securely.

What emergency releases mean for users

Emergency releases only (noticeably) impact the issue that they directly fix. For example, X feature no longer crashes, or Y no longer represents a cybersecurity hole.

Users may have experienced inconvenience or disruption from the bug or vulnerability in question. Their trust in your service may also have dipped. So, for users, emergency releases mean that things either get back or stay on track.

A prompt emergency release, then, means that users can continue to use the software effectively. And, if handled quickly and competently, they can also restore any lost product faith.

总结

主要版本：全面的新升级

次要版本：小的、定期的更新

紧急版本：突然的、非计划的热修复

而且，无论是新版本的软件还是保持运行的关键修复，你的软件发布将影响用户。

因此，要确保他们准备好迎接即将到来的变化。

Major: sweeping new upgrades

Minor: small, regular updates

Emergency: sudden, unplanned hotfixes

And whether it’s a new version of the software or a crucial fix to keep things running, your software releases will impact users.

So, make sure they’re ready for the changes coming their way.

参考：

1，不同软件发布的区别

The three software release types and what they mean for users - Parker Software

2，版本号说明

What do the numbers in a version typically represent (i.e. v1.9.0.1)? - Stack Overflow

3，Wiki的版本号说明

https://en.wikipedia.org/wiki/Software_versioning

扩展阅读：

关于版本号和兼容性的说明

https://medium.com/fiverr-engineering/major-minor-patch-a5298e2e1798