一个版本中的数字通常代表什么(例如 v1.9.0.1) ？

通常是:

主版本。次版本。修订。建立

主要的、次要的、补丁、构建、安全补丁等的组合。

前两个是主要的和次要的——其余的取决于项目、公司，有时也取决于社区。在类似 FreeBSD 的操作系统中，您将使用1.9.0.1 _ number 来表示安全补丁。

版本号通常不代表单独的组件。对某些人/软件来说，这些数字是相当随意的。对于其他版本，版本号字符串的不同部分确实表示不同的内容。例如，当文件格式发生变化时，某些系统会增加版本号的一部分。因此，V1.2.1是与所有其他 V1.2版本(1.2.2、1.2.3等)兼容的文件格式，但与 V1.3不兼容。最终取决于你想使用什么方案。

是的。主要的版本增加了大量的新特性，可能会破坏兼容性或者有明显不同的依赖关系，等等。

次要版本也增加了一些特性，但是它们更小，有时是从 beta 主要版本中精简的移植版本。

如果有第三个版本号组件，那么它通常用于重要的 bug 修复和安全修复。如果有更多的，它真的很大程度上取决于产品，很难给出一般性的答案。

分数越多，释放越小。除此之外，没有真正可靠的标准——可以根据项目维护人员的决定来表示不同的事情。

例如，WordPress 遵循以下思路:

1.6-> 2.0-> 2.0.1-> 2.0.2-> 2.1-> 2.1.1-> 2.2...

1.6到2.0将是一个很大的发布版本——特性、界面变化、 API 的主要变化、一些1.6模板和插件的破坏等等。 2.0到2.0.1将是一个小的发布版本——可能修复了一个安全漏洞。 2.0.2到2.1将是一个重要的发行版——通常是新特性。

这取决于具体情况，但典型的表示形式是 少校，少校，释放，构建。

地点:

• Major 是你软件的主要发行版，想想.NET 3. x
• Small 是您软件的次要发行版，想想.NET x. 5
• Release 是该版本的发行版，通常错误修复会增加这个版本
• Build 是一个数字，表示已执行的构建的数量。

例如，1.9.0.1，意味着它是你的软件的1.9版本，在1.8和1.7之后，等等，1.7,1.8和1.9都以某种方式增加了小量的新功能，同时修复了错误。因为它是 x.x.0.x，所以它是1.9的初始版本，也是该版本的第一个版本。

你也可以在 关于这个话题的维基百科文章上找到好的信息。

大，小，虫子

(或者其他类似的情况)

Bug 通常是没有新功能的 bug 修复。

次要的是一些增加了新功能但不会以任何主要方式改变程序的更改。

Major 是程序中的一个变化，它要么打破了旧的功能，要么太大以至于以某种方式改变了用户应该如何使用程序。

根据语言的不同，例如 Delphi 和 C # 有不同的含义。

通常，前两个数字代表一个主要版本和一个次要版本，比如第一个真正的版本是1.0，一些重要的 bug 修复和次要的新特性是1.1，一个大的新特性版本是2.0。

第三个数字可以指“非常小”的版本，或修订。例如，1.0.1只是1.0.0的一个非常小的错误修复程序。但是它也可以携带来自源代码管理系统的版本号，或者随着每次构建而增加的不断增加的版本号。或者数据戳。

再详细一点。“正式”加入。Net，这4个数字是“少校”。小事。建造。“修订”，而在德尔斐有“主要的。小事。放手。建造”。我用的是“少校”。小事。真的很小。我的版本。

一般来说，数字的格式是 version.Major. minor.hotfix，而不是单独的内部组件。所以 v1.9.0.1应该是版本1，主要版本9(v1) ，次要版本(v1.9)0，热修复版本1(v1.9.0)。

第一个数字通常被称为主版本号。它基本上用于表示构建之间的重大变化(例如，当您添加许多新特性时，您将增加主版本)。来自同一产品的不同主要版本的组件可能不兼容。

下一个数字是次要版本号。它可以表示一些新特性，或者一些 bug 修复或者一些小的体系结构更改。来自同一产品的组件之间的版本号差异很小，它们可能在一起工作，也可能不在一起工作，也可能不应该在一起工作。

下一个通常称为构建号。这可能每天都在增加，或者随着每个“发布”的构建，或者随着每个构建的增加而增加。两个组件之间可能只有很小的差异，它们之间只有构建编号不同，通常可以很好地协同工作。

最后一个数字通常是修订号。这通常被自动构建过程使用，或者当您正在为测试进行“一次性”的一次性构建时。

当您递增您的版本号是由您，但他们应该始终 增量或 保持不变。您可以让所有组件共享相同的版本号，或者只增加已更改组件的版本号。

每个人都会选择他们想用这些数字做什么。我一直试图调用发布 ABC，因为它是相当愚蠢的反正。也就是说，我在过去25多年的发展中看到的趋势是这样的。假设你的版本号是1.2。

“1”表示“重大”修订。通常这是一个初始版本，一个大的特性集改变或重写代码的重要部分。一旦确定了特性集，并且至少部分实现了特性集，就可以转到下一个数字。

“2”表示系列中的一个发布。我们经常利用这个位置来了解在上一个主要版本中没有出现的特性。这个位置(2)几乎总是指示添加功能，通常是修复错误。

大多数商店中的“3”表示补丁发布/bug 修复。几乎从来没有，至少在商业方面，这是否意味着一个重要的功能添加。如果特性出现在位置3，那么可能是因为有人在我们知道必须进行 bug 修复发布之前签入了某些内容。

超过“3”的位置？我不知道人们为什么会做这种事情，这只会让人更困惑。

值得注意的是，一些战略情报局把这些都搞乱了。例如，Trac 版本10实际上是0.10.X.X。我认为 OSS 世界中的许多人要么缺乏信心，要么只是不想宣布他们已经完成了一个主要的发布。

从 C # Assembly blyInfo.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.*")]

一个复杂软件的版本号代表整个软件包，并且与各个部分的版本号无关。Gizmo 版本3.2.5可能包含 Foo 版本1.2.0和 Bar 版本9.5.4。

在创建版本号时，使用它们如下:

1. 第一个数字是主要释放。如果您对用户界面进行了重大更改，或者需要破坏现有的界面(这样您的用户将不得不更改他们的界面代码) ，那么您应该转到新的主版本。

2. 第二个数字应该表明已经添加了新的特性或者内部有什么不同的工作方式。(例如，Oracle 数据库可能决定使用不同的策略来检索数据，使大多数事情变得更快，有些事情变得更慢。)现有的接口应该继续工作，用户界面应该是可识别的。

3. 进一步的版本编号取决于编写软件的人员—— Oracle 使用了5个(!)团体。Oracle 版本类似于10.1.3.0.5。从第三组开始，您应该只引入错误修复或功能上的小更改。

变化较小的应该是前两个，对于 Major. small，之后可以是从构建、修订、发布到任何自定义算法(比如在一些 MS 产品中)的任何内容

每个组织/团体都有自己的标准。重要的是，你要坚持你选择的任何符号，否则你的客户会感到困惑。说到这里，我通常会用到3个数字:

在哪里: 是主要版本(主要新特性) Y: 是次要的版本号(小的新特性，小的改进而不改变 UI) Z: 是服务包(基本上与 x.y 相同，但是有一些 bug 修复 Bbbb: 是构建编号，并且只能从“ about box”中看到其他用于客户支持的详细信息。Bbbb 是免费的格式，每个产品都可以使用自己的。

以下是我们使用的方法:

1. 第一个数字 = 整个系统时代。每隔几年发生一次变化，通常代表着技术或客户端特性或两者的根本性变化。
2. 第二个数字 = 数据库模式修订。这个数字的增加需要数据库迁移，因此需要进行重大更改(或系统复制，因此更改数据库结构需要仔细的升级过程)。如果第一个数字更改，则重置为0。
3. 第三个数字 = 软件只改变。这通常可以在客户端上逐个实现，因为数据库模式是不变的。如果第二个数字更改，则重置为零。
4. 颠覆版本号。我们使用 TortoiseSVN 工具在构建时自动填充它。这个数字从不重置，而是不断增加。使用这个，我们总是可以重新创建任何版本。

这个系统为我们提供了很好的服务，因为每个数字都有明确而重要的功能。我看到其他团队在努力解决大数/小数的问题(多大的变化是主要的) ，我不认为这有什么好处。如果您不需要跟踪数据库修订，只需要到一个3或2位版本号，并使生活更容易！

我认为主要发布，次要发布，bug 修复的范例是很普遍的。

在一些企业支持合同中，$$(或违约责任)与特定版本的指定方式有关。例如，一个合同可能允许客户在一段时间内获得一定数量的主要版本，或者承诺在一段时间内只有少于 x 的次要版本，或者支持将继续可用于如此多的版本。当然，无论合同中用了多少词来解释什么是主要版本，什么是次要版本，它总是主观的，总会有灰色地带——导致软件供应商可以利用系统来打破合同条款的可能性。

数字可以像其他答案所描述的那样有用，但是考虑一下它们是如何变得毫无意义的... ... SUN，你知道 SUN，java: 1.2,1.3,1.41.5或5然后6。 在苹果 II 的旧版本号码中，意味着某些东西。如今，人们正在放弃版本号，改用一些愚蠢的名字，比如“活泼的无花果”(或类似的名字)、“顽强的苍鹭”、“欧罗巴”和“木卫三”。当然这远没有那么有用，因为在你停止改变程序之前，木星的卫星就用完了，而且因为没有明显的顺序，你不能分辨哪个是新的。

人们并不总是能意识到版本号之间的细微差别，比如2.1、2.0.1或2.10——问问技术支持人员他们在这方面遇到了多少麻烦。开发人员是面向细节的，并且熟悉层次结构，所以这对我们来说是一个盲点。

如果可能的话，向您的客户公开一个更简单的版本号。

对于库，版本号告诉您两个版本之间的 兼容性水平兼容性水平，以及升级的难度。

Bug 修复版本需要保持二进制、源和序列化兼容性。

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

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

我写了更多关于 给你的基本原理。

这是 语义版本规范

下面是2.0.0版本的摘要:

给定版本号 MAJOR.MINOR.PATCH，增加:

1. 当您进行不兼容的 API 更改时,
2. 以向后兼容的方式添加功能时的 MINOR 版本，以及
3. 在修复向后兼容的 bug 时使用 PATCH 版本。

用于预发布和构建元数据的附加标签如下所示 对 MAJOR.MINOR.PATCH 格式的扩展。

在版本1.9.0.1中: 这是显式的版本控制方案 ，当您不想在预发布版本中使用名称或者构建类似-alpha、 -beta 的版本时，可以使用这个方案。

主要版本可能会打破向下兼容

9: 添加新特性以支持您的应用程序以及向后兼容以前的版本。

0: 一些小的 bug 修复

1: 版本号(预发布号)

但是现在，你不会找到这样的版本控制方案 Https://semver.org/

版本: v1.9.0.1

在哪里-

.是版本的缩写。公司与公司之间的差异取决于他所在组织采用的术语。在某些组织中，比如1.9.0.1，它可能会保持沉默

表示主要版本，将更新在应用程序堆栈，基础设施(平台)或暴露的网络接口的架构修改

.9个小的，将更新的活动，如添加新的组件，如 ui，API，数据库等; 在一个特定的架构下

0表示功能，将更新任何现有组件(ui，api，数据库等)的增强

.1表示跨所有阶段的主要，次要和功能的构建计数器。它还包括后期制作版本的修补程序。

尽管前面的大多数答案都对如何使用版本号给出了非常好的解释，但是还有另外一种方案，我称之为 市场推广版本管理计划。我将添加这个作为答案，因为它存在，而不是因为我认为它值得遵循。

在 市场推广版本管理计划中，所有这些技术思想和意义都被 越大越好所取代。产品的版本号来自两个规则:

• 较大(较高)的数字比较小(较低)的数字好
• 我们的版本号应该大于(高于)任何竞争对手的版本号

这将版本编号从技术人员的手中拿走，并将其放在属于它的地方(销售和营销)。

然而，由于技术版本在某种程度上仍然有意义，营销版本往往伴随着技术版本号。它们通常以某种方式隐藏，但可以通过一些 信息或 关于对话框显示。