也许这是一个愚蠢的问题，但我总是假设每个数字都用一段时间来描述软件的一个组成部分。如果这是真的，他们会代表不同的东西吗？我想开始为我的软件的不同版本分配版本，但我不确定它应该如何构建。我的软件有五个不同的组件。
答案 0 :(得分：162)
版本 1.9.0.1 ：
1 ：主要修订版（新用户界面，许多新功能，概念变化等）
9 ：小修订版（可能是对搜索框的更改，添加了1个功能，修复了错误）
0 ：错误修复发布
1 ：内部版本号（如果使用） - 这就是为什么你看到使用类似2.0.4.2709的.NET框架
你不会发现很多应用程序分为四个等级，3通常就足够了。
答案 1 :(得分：16)
有Semantic Versioning specification
这是2.0版的摘要：
给定版本号MAJOR.MINOR.PATCH，增加：
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.预发布和构建元数据的其他标签可用作 MAJOR.MINOR.PATCH格式的扩展。
答案 2 :(得分：13)
它可以是非常随意的，并且因产品而异。例如，对于Ubuntu发行版，8.04指的是2008.April
通常，最左侧（主要）数字表示主要版本，右侧越远，所涉及的变化越小。
答案 3 :(得分：12)
MAJOR.MINOR [.maintenance [.build]]
答案 4 :(得分：8)
其他答案所描述的数字可能很有用，但请考虑它们如何也可能毫无意义......太阳，你知道SUN，java：1.2,1.3,1.4 1.5或5然后6。 在旧的Apple II版本编号Meant Something。如今，人们正在放弃版本号，并使用愚蠢的名字，如“Feisty fig”（或类似的东西）和“hardy heron”，“europa”和“ganymede”。当然，这远没那么有用，因为在你停止更改程序之前，你将会用完木星的卫星，而且由于没有明显的顺序，你无法分辨哪个更新。
答案 5 :(得分：7)
点数越多，释放越小。除此之外没有真正可靠的标准 - 根据项目维护者的决定，可能意味着不同的东西。
例如，WordPress就是这样说的：1.6 - ＆gt; 2.0 - ＆gt; 2.0.1 - ＆gt; 2.0.2 - ＆gt; 2.1 - ＆gt; 2.1.1 - ＆gt; 2.2 ......
1.6到2.0将是一个重要的版本 - 功能，界面更改，API的重大更改，一些1.6模板和插件的破坏等。 2.0到2.0.1将是次要版本 - 可能修复了一个安全漏洞。 2.0.2到2.1将是重要的发布 - 通常是新功能。
答案 6 :(得分：4)
数字可能意味着您想要的任何内容，尽管它们通常与单个组件无关，而是与您的发布中的主要与次要与维护更改相关。
查看这些资源：
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html
干杯
答案 7 :(得分：3)
版本号通常不代表单独的组件。对于某些人/软件，这些数字相当随意。对于其他人，版本号字符串的不同部分确实代表不同的东西。例如，某些系统会在文件格式更改时增加部分版本号。所以V 1.2.1是与所有其他V 1.2版本（1.2.2,1.2.3等）兼容的文件格式，但与V 1.3不兼容。最终，由您决定使用哪种方案。
答案 8 :(得分：2)
答案 9 :(得分：2)
从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.*")]
答案 10 :(得分：2)
Major.Minor.Bugs
（或者有些变化）
错误通常是错误修复，没有新功能。
Minor是一些添加新功能的更改，但不会以任何主要方式更改程序。
主要是程序的变化，要么破坏旧功能，要么变得太大，以至于它以某种方式改变用户应该如何使用该程序。
答案 11 :(得分：2)
取决于，但典型的代表是 major.minor.release.build 。
其中：
因此，例如，1.9.0.1，意味着它是你的软件的1.9版，遵循1.8和1.7等，其中1.7,1.8和1.9在某些方面通常会添加少量的新功能以及错误修正。由于它是x.x.0.x，它是1.9的初始版本，它是该版本的第一个版本。
您还可以在Wikipedia article on the subject找到很好的信息。
答案 12 :(得分：1)
烨。主要版本添加了大的新功能，可能会破坏兼容性或具有显着不同的依赖性等。
次要版本还添加了功能，但它们是较小的，有时是从beta主要版本中删除的移植版本。
如果有第三个版本号组件，通常用于重要的错误修正和安全修复。如果有更多，它实际上很大程度上取决于产品，很难给出一般答案。
答案 13 :(得分：1)
在v1.9.0.1版本中： 这是显式的版本控制方案，当您不想在预发行版中使用名称或不希望使用-alpha，-beta之类的版本时使用。
1：主要版本可能会破坏向后兼容性
9：添加了新功能以支持您的应用，并向后兼容以前的版本。
0：一些小错误修复
1：内部版本号（预发行版号）
但是现在，您将找不到这样的版本控制方案。请参考语义版本控制[semver2.0] https://semver.org/
答案 14 :(得分：1)
通常是：
MajorVersion.MinorVersion.Revision.Build
答案 15 :(得分：1)
对于库，版本号会告诉您两个版本之间的兼容性级别，因此升级会有多困难。
错误修复版本需要保留二进制，源代码和序列化兼容性。
次要版本对不同的项目意味着不同的东西，但通常他们不需要保持源兼容性。
主要版本号可以打破所有三种形式。
我写了更多关于理由here。
答案 16 :(得分：1)
每个人都选择他们想要对这些数字做什么。我一直想把它发布给a.b.c，因为它反正很傻。话虽这么说，我在过去25多年的发展中看到的往往是这样的。假设你的版本号是1.2.3。
“1”表示“主要”修订版。通常这是初始版本，大型功能集更改或重写代码的重要部分。确定功能集并至少部分实现后，转到下一个数字。
“2”表示系列中的发布。通常我们会使用这个位置来捕获在上一个主要版本中没有出现的功能。这个位置（2）几乎总是表示功能添加，通常有错误修复。
大多数商店中的“3”表示补丁发布/错误修复。几乎从来没有，至少在商业方面，这表明一个重要的功能增加。如果功能出现在第3位，那么可能是因为有人在我们知道我们必须修复错误之前检查了一些内容。
超越“3”的位置？我不知道为什么人们会这样做，它会让人更加困惑。
值得注意的是，那里的一些OSS抛出了所有这些。例如，Trac版本10实际上是0.10.X.X.我认为OSS世界中的很多人要么缺乏信心，要么就是不想宣布他们已经完成了重大发布。
答案 17 :(得分：1)
答案 18 :(得分：1)
人们并不总是认识到版本号如2.1,2.0.1或2.10之间的细微差别 - 向技术支持人员询问他们多少次遇到此问题。开发人员注重细节，熟悉层次结构，因此这对我们来说是一个盲点。
如果可能，请向客户公开更简单的版本号。
答案 19 :(得分：1)
主要版本的范例.minor release.bug修复很常见，我想。
在某些企业支持合同中，存在与指定特定版本的方式相关的$$$（或违反合同责任）。例如，合同可能会在一段时间内让客户获得一些主要版本，或者承诺在一段时间内将有少于x个次要版本，或者支持将继续为这么多版本提供支持版本。当然，无论合同中有多少单词用于解释主要版本与次要版本的对比，它总是主观的，并且总会有灰色区域 - 导致软件供应商可以将系统游戏到打败了这样的合同条款。
答案 20 :(得分：0)
版本：v1.9.0.1
其中-
。 v是version的缩写。各个公司的情况各不相同，这取决于其组织采用的术语。在某些组织（如1.9.0.1）中它可能会保持沉默
。 1表示主要版本，将在应用程序堆栈，基础架构（平台）或公开网络接口中的体系结构修改上进行更新
。 9个未成年人，将在活动上进行更新，例如添加新组件，例如ui，api，数据库等；在特定的架构下
。 0表示功能，将在现有组件（ui，api，数据库等）的所有增强功能上进行更新
。 1表示所有主要，次要和功能阶段的构建计数器。它还包括生产发布后的修补程序。
答案 21 :(得分：0)
以下是我们使用的内容：
这个系统很好地为我们服务，因为每个数字都有明确而重要的功能。我见过其他团队正在努力解决主要的数字/次要问题（主要的变化有多大），而且我没有看到这样的好处。如果您不需要跟踪数据库修订版，只需转到3位或2位数的版本号，让生活更轻松！
答案 22 :(得分：0)
每个组织/团体都有自己的标准。重要的是你坚持你选择的任何符号，否则你的客户会感到困惑。说过我通常使用3个数字：
x.yz.bbbbb。哪里： x：是主要版本（主要新功能） y：是次要版本号（小的新功能，没有UI更改的小改进） z：是服务包（基本上与x.y相同，但有一些错误修复 bbbb：是内部版本号，只有“关于框”才能真正显示，其中包含客户支持的其他详细信息。 bbbb是免费格式，每个产品都可以使用它。
答案 23 :(得分：0)
答案 24 :(得分：0)
答案 25 :(得分：0)
复杂软件的版本号代表整个软件包，与零件的版本号无关。 Gizmo版本3.2.5可能包含Foo版本1.2.0和Bar版本9.5.4。
创建版本号时，请按如下方式使用它们：
第一个号码是主要版本。如果您对用户界面进行了重大更改或需要破坏现有界面（以便您的用户必须更改其界面代码），您应该转到新的主版本。
第二个数字应表示已添加新功能或内部工作方式不同。 （例如，Oracle数据库可能决定使用不同的策略来检索数据，使大多数事情更快，而且速度更慢。）现有接口应该继续工作，用户界面应该是可识别的。
版本编号还取决于编写软件的人 - Oracle使用五个（！）组，即。 Oracle版本类似于10.1.3.0.5。从第三组开始，您应该只介绍错误修正或功能上的细微更改。
答案 26 :(得分：0)
第一个数字通常称为主要版本号。它基本上用于表示构建之间的重大更改（即，当您添加许多新功能时，您会增加主要版本）。具有不同主要版本的组件可能与同一产品不兼容。
下一个号码是次要版本号。它可以代表一些新功能，或许多错误修复或小型架构更改。同一产品中由次要版本号不同的组件可能会也可能不会一起工作，也可能不会。
下一个通常称为内部版本号。这可以每天增加，或者每个“已发布”构建，或者根据每个构建增加。两个组件之间可能只有很小的差异，这些组件只有内部版本号不同，通常可以很好地协同工作。
最终的数字通常是修订号。通常情况下，这是由自动构建过程使用，或者当您为测试制作“一次性”丢弃构建时。
当您增加版本号时，由您决定，但它们应始终增量或保持不变。您可以让所有组件共享相同的版本号，或仅增加已更改组件的版本号。
答案 27 :(得分：0)
通常，number的格式为version.major.minor.hotfix，而不是单个内部组件。所以v1.9.0.1将是版本1，主要版本9（v1），次要版本（v1.9）0，热修复1（v1.9.0）。
答案 28 :(得分：0)
取决于语言，例如Delphi和C＃有不同的含义。
通常情况下，前两个数字代表主要版本和次要版本，即第一个真正版本为1.0，一些重要错误修正版本为1.1，小版本新版本为2.0，大型新功能版本为2.0。
第三个数字可以指“真正次要”的版本或修订版。例如，1.0.1只是1.0.0的一个非常小的错误修正。但是它也可以携带源代码管理系统中的版本号，或者随着每次构建而递增的递增编号。或者是一个日期戳。
更详细一点here。 “正式”，在.net中，4个数字是“Major.Minor.Build.Revision”，而在Delphi中有“Major.Minor.Release.Build”。我使用“Major.Minor.ReallyMinor.SubversionRev”进行版本控制。
答案 29 :(得分：0)
主要，次要，补丁，构建，安全补丁等的组合
前两个是主要＆amp;未成年人 - 其余将取决于项目，公司，有时还有社区。在像FreeBSD这样的操作系统中，你将有1.9.0.1_number代表一个安全补丁。