版本中的数字通常代表什么(即v1.9.0.1)？

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

也许这是一个愚蠢的问题，但是我一直假定每个用句点表示的数字代表软件的单个组件。如果是这样，那么他们代表过什么吗？我想开始为软件的不同内部版本分配版本，但我不确定该如何组织。我的软件有五个不同的组件。

在1.9.0.1版中：

1：主要修订(新用户界面，许多新功能，概念更改等)
9：次要修订版(可能是对搜索框的更改，1个功能的添加，错误修复的集合)
0：错误修复版本
1：内部版本号(如果使用)—这就是为什么您看到使用诸如2.0.4.2709之类的.NET框架的原因

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

有语义版本控制规范

这是2.0版的摘要：

Given a version number MAJOR.MINOR.PATCH, increment the:

1
2
3
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.

它可以是非常任意的，并且因产品而异。例如，在Ubuntu发行版中，8.04指的是2008年4月。

通常，最左边(主要)的数字表示主要版本，而您向右移动得越远，涉及的更改就越小。

major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#数字

如其他答案所述，数字可能会有用，但请考虑一下数字也可能毫无意义... Sun，您知道SUN，java：1.2、1.3、1.4、1.5或5，然后是6。
在良好的旧版Apple II版本中，数字意味着什么。如今，人们放弃了版本号，取而代之的是愚蠢的名称，例如" Feisty fig"(或类似名称)，" hardy heron"，" europa"和" ganymede"。当然，这没什么用，因为，在停止更改程序之前，您将耗尽木星的卫星，并且由于没有明显的命令，您无法分辨哪个是新的。

得分越多，发行量就越小。除此之外，没有真正的坚实标准-可以根据项目维护者的决定来表示不同的含义。

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

数字通常可以表示您想要的任何内容，尽管它们通常与各个组件无关，而与发行版中的主要变更，次要变更和维护变更无关。

查看以下资源：
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html

干杯

版本号通常不代表单独的组件。对于某些人/软件，这个数字是相当任意的。对于其他版本，版本号字符串的不同部分确实代表不同的内容。例如，某些系统在文件格式更改时增加版本号的一部分。因此，V 1.2.1是与所有其他V 1.2版本(1.2.2、1.2.3等)兼容的文件格式，但与V 1.3不兼容。最终由您决定要使用哪种方案。

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

哪里：

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

因此，例如1.9.0.1，意味着它是软件的1.9版本，紧随1.8和1.7等。其中1.7、1.8和1.9通常都以某种方式添加了一些新功能以及错误修正。由于它是x.x.0.x，因此它是1.9的初始版本，并且是该版本的第一个版本。

您也可以在有关该主题的Wikipedia文章上找到良好的信息。

大，小，虫

(或对此的一些变化)

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

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

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

通常是：

MajorVersion.MinorVersion.Revision.Build

在v1.9.0.1版本中：
当您不想在预发行版中使用名称或像-alpha，-beta这样的版本时，这是使用的显式版本控制方案。

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

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

0：一些小错误修复

1：内部版本号(预发行号)

但如今，您将找不到这样的版本控制方案。请参阅语义版本控制[semver2.0]
https://semver.org/

每个人都可以选择要使用这些数字的方式。我一直很想将发布称为a.b.c，因为无论如何还是很愚蠢的。话虽这么说，但我在过去25多年的发展中所看到的倾向于这种方式。假设您的版本号是1.2.3。

" 1"表示"主要"修订。通常，这是一个初始发行版，一个较大的功能集更改或一个代码的重要部分的重写。确定功能集并至少部分实现该功能集后，您将转到下一个数字。

" 2"表示系列中的版本。通常，我们使用这个职位来掌握在上一个主要版本中没有的功能。这个位置(2)几乎总是表示功能已添加，通常带有错误修复。

大多数商店中的" 3"表示补丁程序发布/错误修复。至少在商业方面，几乎从来没有这表明增加了重要的功能。如果功能显示在位置3，则可能是因为有人在我们知道必须进行bug修复发行之前签入了某些内容。

超越" 3"位？我不知道人们为什么要做这种事情，这只会变得更加令人困惑。

值得注意的是，其中一些OSS使得所有这些都不合理。例如，Trac版本10实际上是0.10.X.X。我认为OSS世界中的许多人要么缺乏信心，要么就是不想宣布他们已经完成了重要的发布。

从C＃AssemblyInfo.cs文件中，您可以看到以下内容：

1
2
3
4
5
6
7
8
9
10

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

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

我认为主要的release.minor release.bug修复模式很普遍。

在某些企业支持合同中，与特定发布版本的指定方式相关的$$$$($(或违反合同责任))。例如，一份合同可能使客户有权在一段时间内获得一些主要版本，或者承诺一个时期内次要版本的数量少于x，或者可以继续为许多客户提供支持发布。当然，无论合同中用多少字来解释什么是主要发行版还是次要发行版，它始终是主观的，并且始终存在灰色区域–从而导致软件供应商可以将系统玩违反此类合同规定。

人们并不总是意识到版本号(例如2.1、2.0.1或2.10)之间的细微差别-向技术支持人员咨询他们遇到此问题的次数。开发人员注重细节并且熟悉层次结构，因此这对我们是一个盲点。

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

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

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

次要发行版对不同的项目意味着不同的事情，但是通常它们不需要保持源兼容性。

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

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

对。主要版本添加了重要的新功能，可能会破坏兼容性或具有明显不同的依赖性等。

次要版本也添加了功能，但它们较小，有时从beta主要版本中精简移植的版本。

如果有第三个版本号组件，则通常用于重要的错误修正和安全性修正。如果还有更多，那么它实际上取决于产品，因此很难给出一般性答案。

Major.minor.point.build通常。 Major和minor是不言自明的，point是针对一些次要错误修正的发行版，而build只是一个构建标识符。

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

下一个数字是次要版本号。它可以代表一些新功能，或许多错误修复或小的体系结构更改。同一产品中的组件的次要版本号不同，它们可能会或可能不会一起工作，也可能无法一起工作。

下一个通常称为内部版本号。这可能每天增加一次，也可能随着每个"已发布"的版本，或者与每个版本一起增加。两个组件之间可能只有很小的差异，它们之间的差异仅是内部版本号，并且通常可以很好地协同工作。

最终编号通常是修订号。通常，它会被自动构建过程使用，或者在进行"一次性"一次性构建的测试时使用。

当您增加版本号时，取决于您，但是它们应该始终增加或保持不变。您可以使所有组件共享相同的版本号，或者仅增加已更改组件的版本号。

主要，次要，补丁，内部版本，安全补丁等的组合

前两个是主要和次要-其余将取决于项目，公司以及有时取决于社区。在像FreeBSD这样的操作系统中，您将有1.9.0.1_number代表一个安全补丁。

通常，编号采用version.major.minor.hotfix的格式，而不是各个内部组件的格式。因此，v1.9.0.1将是版本1(主要是v1)，次要版本9(是v1.9)0，是修订版1(是v1.9.0)。

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

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

第一个数字是主要版本。如果您对用户界面进行了重大更改或需要中断现有界面(以便用户必须更改其界面代码)，则应使用新的主版本。

第二个数字应表示已添加了新功能或内部某些功能不同。 (例如，Oracle数据库可能决定使用其他策略来检索数据，从而使大多数事情变得更快而某些事情变得更慢。)现有的界面应继续工作，并且用户界面应可识别。

版本编号进一步取决于编写软件的人-Oracle使用五个(！)组，即。 Oracle版本类似于10.1.3.0.5。从第三组开始，您应该只引入错误修正或功能上的较小更改。

关于软件构建过程的注意事项

对于major.minor，变化较小的将是前两个，之后可以是从构建，修订，发行到任何自定义算法的任何内容(例如某些MS产品)

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

x.yz.bbbbb。哪里：
x：是主要版本(主要新功能)
y：是次要版本号(小的新功能，没有UI更改的小的改进)
z：是Service Pack(与x.y基本相同，但已修复了一些错误)
bbbb：是内部版本号，仅在"关于"框中带有其他详细信息才能真正得到客户支持。 bbbb是免费格式，每个产品都可以使用它自己的格式。

这是我们使用的：

第一个数字=整个系统时代。每两年更改一次，通常代表技术或客户功能或两者的根本变化。

第二个数字=数据库架构修订。此数字的增加需要数据库迁移，因此是一个重大更改(或系统复制，因此更改数据库结构需要仔细的升级过程)。如果第一个数字更改，则重置为0。

第三个数字=仅软件更改。由于数据库架构不变，因此通常可以在每个客户端的基础上实现。如果第二个数字更改，则重置为零。

Subversion版本号。我们使用TortoiseSVN工具在构建时自动填充它。此数字从不重置，但会不断增加。使用此方法，我们始终可以重新创建任何版本。

该系统对我们有好处，因为每个数字都具有明确而重要的功能。我已经看到其他团队在努力解决主要数字/次要数字问题(重大变化有多大)，但我看不出这样做有何好处。如果您不需要跟踪数据库修订，只需使用3位或2位数字的版本号即可，使工作更轻松！

取决于语言，例如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"进行版本控制。