versions - 版本中的数字通常代表什么（即 v1.9.0.1）？

Question

也许这是一个愚蠢的问题，但我一直认为用句点描绘的每个数字代表软件的一个组件。如果这是真的，它们是否代表了不同的东西？我想开始为我的软件的不同版本分配版本，但我不确定它应该如何构建。我的软件有五个不同的组件。

score 235 · Accepted Answer

在版本1.9.0.1 中：

1：重大修订（新 UI、许多新功能、概念变化等）
9：次要修订（可能是对搜索框的更改，添加了 1 个功能，错误修复的集合）
0：错误修复发布
1：内部版本号（如果使用）——这就是为什么你看到 .NET 框架使用类似 2.0.4.2709 的东西

您不会发现很多应用程序会下降到四个级别，通常 3 个就足够了。

score 44 · Accepted Answer

有语义版本控制规范

这是2.0.0版本的总结：

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

进行不兼容的 API 更改时的主要版本，

以向后兼容的方式添加功能时的次要版本，以及

进行向后兼容的错误修复时的补丁版本。

预发布和构建元数据的附加标签可作为 MAJOR.MINOR.PATCH 格式的扩展。

score 17 · Accepted Answer

它可以是非常任意的，并且因产品而异。例如，对于 Ubuntu 发行版，8.04 指的是 2008.April

通常，最左边（主要）的数字表示主要版本，并且越往右，所涉及的更改越小。

score 12 · Accepted Answer

12

主要.次要[.maintenance[.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

于 2008-09-15T19:04:19.530 回答

score 9 · Accepted Answer

正如其他答案所描述的那样，数字可能很有用，但考虑一下它们如何也可能毫无意义...... Sun，你知道 SUN，java：1.2、1.3、1.4 1.5 或 5 然后 6。在旧的 Apple II 版本中，数字意味着某物。如今，人们放弃了版本号，取了一些愚蠢的名字，比如“Feisty fig”（或类似的东西）、“hardy heron”、“europa”和“ganymede”。当然，这用处不大，因为在停止更改程序之前，您将用完木星的卫星，并且由于没有明显的顺序，您无法分辨哪个是更新的。

score 8 · Accepted Answer

点数越多，释放越小。除此之外没有真正可靠的标准 - 根据项目维护者的决定可能意味着不同的事情。

例如，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 将是一个重要的版本——通常是新功能。

score 4 · Accepted Answer

在 v1.9.0.1 版本中：这是在您不想为预发布使用名称或构建类似 -alpha、-beta 时使用的显式版本控制方案。

1：可能破坏向后兼容性的主要版本

9：添加新功能以支持您的应用程序以及与以前版本的向后兼容性。

0：一些小错误修复

1：内部版本号（预发布号）

但现在，你不会找到这样的版本控制方案。请参考语义版本控制 [semver2.0] https://semver.org/

score 3 · Accepted Answer

3

release.major.minor.revision 将是我的猜测。
但产品之间的差异可能很大。

于 2008-09-15T19:03:46.787 回答

score 3 · Accepted Answer

版本号通常不代表单独的组件。对于某些人/软件来说，数字是相当随意的。对于其他人来说，版本号字符串的不同部分确实代表不同的东西。例如，某些系统会在文件格式更改时增加部分版本号。所以 V 1.2.1 是与所有其他 V 1.2 版本（1.2.2、1.2.3 等）兼容的文件格式，但与 V 1.3 不兼容。最终取决于您要使用哪种方案。

score 2 · Accepted Answer

2

通常它的：

MajorVersion.MinorVersion.Revision.Build

于 2008-09-15T19:04:46.330 回答

score 2 · Accepted Answer

这取决于，但典型的表示是major.minor.release.build。

在哪里：

major是您的软件的主要发布版本，例如 .NET 3.x
次要是您的软件的次要版本，例如 .NET x.5
release是该版本的发布，通常错误修正会增加这个
build是一个数字，表示您已执行的构建次数。

例如，1.9.0.1 意味着它是您的软件的 1.9 版，在 1.8 和 1.7 等之后。其中 1.7、1.8 和 1.9 都以某种方式通常会在错误修复的同时添加少量新功能。由于它是 xx0.x，它是 1.9 的初始版本，也是该版本的第一个版本。

您还可以在有关该主题的 Wikipedia 文章中找到很好的信息。

score 2 · Accepted Answer

主要.次要.错误

（或对此的一些变化）

错误通常是没有新功能的错误修复。

Minor 是一些添加新功能但不会以任何主要方式更改程序的更改。

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

score 2 · Accepted Answer

每个人都选择他们想用这些数字做什么。我一直很想将releases称为abc，因为无论如何它都相当愚蠢。话虽如此，我在过去 25 多年的发展中所看到的往往是这样的。假设您的版本号是 1.2.3。

“1”表示“主要”修订。通常这是初始版本、大型功能集更改或重要部分代码的重写。一旦确定了功能集并至少部分实现了，您将转到下一个数字。

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

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

超越“3”的位置？我不知道为什么人们会做那种事情，它只会变得更加混乱。

值得注意的是，那里的一些 OSS 将所有这些都搞砸了。例如，Trac 版本 10 实际上是 0.10.XX 我认为 OSS 世界中的很多人要么缺乏信心，要么只是不想宣布他们已经完成了主要版本。

score 1 · Accepted Answer

Major.minor.point.build 通常。Major 和 minor 是不言自明的，point 是一些小错误修复的发布，而 build 只是一个构建标识符。

score 1 · Accepted Answer

是的。主要版本添加了大的新功能，可能会破坏兼容性或具有显着不同的依赖关系等。

次要版本也添加了功能，但它们更小，有时是来自 beta 主要版本的精简移植版本。

如果有第三个版本号组件，它通常用于重要的错误修复和安全修复。如果还有更多，它真的非常依赖于产品，很难给出一般性的答案。

score 1 · Accepted Answer

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

score 1 · Accepted Answer

从 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.*")]

score 1 · Accepted Answer

我认为主要版本.次要版本.bug 修复的范式很常见。

在某些企业支持合同中，存在与如何指定特定版本相关的 $$$（或违反合同责任）。例如，一份合同可能授权客户在一段时间内获得一定数量的主要版本，或者承诺在一段时间内将有少于 x 个次要版本，或者将继续为这么多的版本提供支持发布。当然，无论在合同中写了多少字来解释什么是主要版本和次要版本，它始终是主观的，并且总是存在灰色区域 - 导致软件供应商可以将系统游戏到击败此类合同条款。

score 1 · Accepted Answer

人们并不总是能识别出 2.1、2.0.1 或 2.10 等版本号之间的细微差别——询问技术支持人员他们遇到过多少次问题。开发人员注重细节，熟悉层次结构，所以这对我们来说是一个盲点。

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

score 1 · Accepted Answer

在库的情况下，版本号告诉您两个版本之间的兼容性级别，以及升级的难度。

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

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

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

我在这里写了更多关于基本原理的文章。

score 0 · Accepted Answer

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

前两个是主要的和次要的——其余的将取决于项目、公司，有时还取决于社区。在像 FreeBSD 这样的操作系统中，您将拥有 1.9.0.1_number 来表示安全补丁。

score 0 · Accepted Answer

取决于语言，例如 Delphi 和 C# 有不同的含义。

通常，前两个数字代表主要和次要版本，即 1.0 表示第一个真正的版本，1.1 表示一些重要的错误修复和次要新功能，2.0 表示大的新功能版本。

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

这里稍微详细一点。“正式”，在 .net 中，4 个数字是“Major.Minor.Build.Revision”，而在 Delphi 中有“Major.Minor.Release.Build”。我使用“Major.Minor.ReallyMinor.SubversionRev”进行版本控制。

score 0 · Accepted Answer

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

下一个数字是次要版本号。它可以代表一些新功能，或者一些错误修复或小的架构更改。来自同一产品的不同次要版本号的组件可能会或可能不会一起工作，并且可能不应该一起工作。

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

最终编号通常是修订号。这通常由自动构建过程使用，或者当您制作“一次性”一次性构建以进行测试时。

当您增加版本号时，由您决定，但它们应该始终增加或保持不变。您可以让所有组件共享相同的版本号，或仅在更改的组件上增加版本号。

score 0 · Accepted Answer

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

创建版本号时，按如下方式使用它们：

第一个数字是主要版本。如果您对用户界面进行了重大更改或需要破坏现有界面（这样您的用户将不得不更改他们的界面代码），您应该转到新的主版本。
第二个数字应表明已添加新功能或内部工作方式有所不同。（例如，Oracle 数据库可能决定使用不同的策略来检索数据，使大多数事情变得更快，而让一些事情变慢。）现有的界面应该继续工作并且用户界面应该是可识别的。
版本编号进一步取决于编写软件的人 - Oracle 使用五个（！）组，即。Oracle 版本类似于 10.1.3.0.5。从第三组开始，您应该只引入错误修复或功能上的微小更改。

score 0 · Accepted Answer

对于major.minor，变化较小的是前两个，之后它可以是从构建、修订、发布到任何自定义算法（如在某些MS产品中）的任何东西

score 0 · Accepted Answer

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

x.yz.bbbbb。其中： x：是主要版本（主要的新功能） y：是次要版本号（小的新功能，没有 UI 更改的小改进） z：是服务包（与 xy 基本相同，但有一些错误修复 bbbb：是内部版本号，只有在“关于框”中才能真正看到，还有其他详细信息供客户支持。bbbb 是免费格式，每个产品都可以使用它自己的。

score 0 · Accepted Answer

这是我们使用的：

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

这个系统很好地为我们服务，因为每个数字都有一个明确而重要的功能。我看到其他团队正在努力解决主要数字/次要数字的问题（主要的变化有多大），我看不到这样做的好处。如果您不需要跟踪数据库修订，只需转到 3 或 2 位版本号，让生活更轻松！

score 0 · Accepted Answer

版本：v1.9.0.1

在哪里-

. v 是版本的缩写。它因公司而异，取决于其组织中采用的命名法。在像 1.9.0.1 这样的组织中它可能会保持沉默

. 1 表示主要版本，将在应用程序堆栈、基础设施（平台）或暴露的网络接口中的架构修改时更新

. 9 incates 次要，将更新活动，如添加新组件，如 ui、api、数据库等；在特定架构下

. 0 表示功能，将在现有组件（ui、api、数据库等）的任何增强上进行更新

. 1 表示跨所有主要阶段、次要阶段和特征的构建计数器。它还包括发布后的修补程序。

score 0 · Accepted Answer

尽管前面的大多数答案都很好地解释了如何使用版本编号，但还有另一种方案，我称之为营销版本方案。我将其添加为答案，因为它存在，而不是因为我认为值得关注。

在营销版本方案中，所有那些技术思想和意义都被更大更好所取代。产品的版本号来源于两个规则：

较大（较高）的数字优于较小（较低）的数字
我们的版本号应该大于（高于）任何竞争对手的版本号

这将版本编号从技术人员手中转移到它所属的地方（销售和营销）。

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

versions - 版本中的数字通常代表什么（即 v1.9.0.1）？

29 回答 29

Related

Reference