一个版本中的数字通常代表什么（即v1.9.0.1）？
也许这是一个愚蠢的问题，但我一直认为每个数字都是由一个代表软件单个组成部分的周期划定的。 如果那是真的，他们是否代表不同的东西？ 我想开始为我的软件的不同版本分配版本，但我不确定应该如何构build它。 我的软件有五个不同的组件。
在版本1.9.0.1中 ：
-
1 ：重大修改（新UI，许多新function，概念改变等）
-
9 ：小修订（可能是对search框的更改，添加了1个function，错误修复的集合）
-
0 ：错误修复版本
-
1 ：内部编号（如果使用的话） – 这就是为什么你使用2.0.4.2709之类的东西来看.NET框架
你不会find很多应用程序下降到四个级别，3通常是足够的。
它可以是非常随意的，因产品而异。 例如，在Ubuntu发行版中，8.04指的是2008.四月
通常情况下，最左边的（主要）数字表示主要版本，而您越往右边则涉及的变化越小。
MAJOR.MINOR [.maintenance [.build]]
数字可能是有用的，如其他答案所描述的，但考虑它们也可能是相当无意义的。Sun，你知道SUN，java：1.2,1.3,1.4,1.5或5，然后是6.在旧的Apple II版本号Meant一些东西。 如今，人们放弃了版本号，并且用“可怕的无花果”（或类似的东西），“强壮的苍鹭”，“欧罗巴”和“Ganymede”等愚蠢的名字。 当然，这样做的用处不大，因为在你停止改变程序之前，你将会用完木星的卫星，而且由于没有明显的顺序，你不能分辨哪个更新。
“给定一个版本号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. 预发布和构build元数据的其他标签可作为MAJOR.MINOR.PATCH格式的扩展使用。
越多的点，释放越小。 除此之外，还没有真正的坚实标准 – 根据项目维护者的决定可能意味着不同的事情。
WordPress，例如，沿着这些线路：
1.6 – > 2.0 – > 2.0.1 – > 2.0.2 – > 2.1 – > 2.1.1 – > 2.2 …
1.6到2.0会是一个很大的版本 – function，界面的变化，对API的重大改变，一些1.6模板和插件的破坏等等。2.0到2.0.1是一个小的版本 – 可能修复一个安全漏洞。 2.0.2到2.1将是一个重要的版本 – 通常是新特性。
数字可以意味着任何你想要的东西，尽pipe它们通常与个别组件无关，而是与你的发行版中的主要维护与次要维护更改相关。
看看这些资源：
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html
干杯
版本号通常不代表单独的组件。 对于某些人/软件来说，这些数字是相当随意的。 对于其他人，版本号string的不同部分确实代表不同的东西。 例如，当文件格式改变时，一些系统会增加部分版本号。 所以V 1.2.1是与所有其他V 1.2版本（1.2.2,1.2.3等）兼容的文件格式，但与V 1.3不兼容。 最终取决于你想要使用什么scheme。
这取决于，但典型的代表是major.minor.release.build 。
哪里：
- 主要是你的软件的主要版本，认为.NET 3.x
- minor是你的软件的小版本版本，比如.NET x.5
- 版本是该版本的发布版本，通常错误修复会增加此版本
- 构build是一个数字，表示您已经完成的构build数量。
因此，例如1.9.0.1，意味着你的软件是1.8和1.7之后的版本1.9，其中1.7,1.8和1.9都以某种方式添加了less量的新function以及缺陷修正。 由于它是xx0.x，它是1.9的最初版本，而且是该版本的第一个版本。
你也可以在维基百科上find关于这个主题的文章 。
从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.*")]
Major.minor.point.build通常。 主要和次要都是不言而喻的，点是几个小错误修正的发布，而构build只是一个构build标识符。
通常它的：
MajorVersion.MinorVersion.Revision.Build
对。 主要版本添加大的新function，可能会打破兼容性或具有明显不同的依赖性等。
次要版本也增加了function，但是它们是较小的版本，有时候是从beta版本发布的简化版本。
如果有第三个版本号的组件，通常是重要的错误修正和安全修复。 如果还有更多的话，那么产品真的非常依赖，很难给出一般的答案。
Major.Minor.Bugs
（或者有一些变化）
错误通常是没有新function的错误修复。
次要的是一些改变，增加了新的function，但不以任何主要的方式改变程序。
Major是程序中的一个变化，它要么破坏旧function，要么变得如此之大，以至于改变了用户应该如何使用这个程序。
每个人都select他们想要做的这些数字。 我一直很想调用abc版本，因为无论如何都是很愚蠢的。 这就是说，在过去25多年的发展中，我所看到的往往是这样工作的。 假设你的版本号是1.2.3。
“1”表示“主要”修订。 通常这是一个初始版本，大的function集更改或重写代码的重要部分。 一旦确定了function集并至less部分实现了function，就可以进入下一个数字。
“2”表示系列中的一个版本。 我们经常使用这个位置来抓住那些在最近的主要版本中没有做到的function。 这个位置（2）几乎总是表示一个function添加，通常与错误修复。
大多数商店中的“3”表示补丁发布/错误修复。 至less在商业方面，几乎从来没有，这是否表明一个重要的特征增加。 如果function显示在位置3，那么可能是因为有人在我们知道必须执行错误修复发布之前检查了某些内容。
超越“3”的位置？ 我不知道为什么人们会这样做，只是变得更加混乱。
值得注意的是，在那里的一些OSS抛出这个怪事。 例如，Trac版本10实际上是0.10.XX我认为OSS世界的很多人缺乏自信，或者只是不想宣布他们已经完成了主要版本。
主要发布.minor release.bug修复的范例是相当普遍的，我想。
在某些企业支持合同中，与特定版本的指定方式相关的是$$$（或违反合同责任）。 例如，一份合同可能会在一段时间内让客户获得一定数量的主要版本，或者承诺在一段时间内less于x个次要版本，或者这种支持将继续可用版本。 当然，不pipe合同中有多less文字来解释主要版本与次要版本之间的关系，它总是存在主观性，总是存在灰色地带 – 导致软件供应商可以将系统游戏到打败这样的合同条款。
在库的情况下，版本号会告诉您两个版本之间的兼容性级别 ，因此升级将有多困难。
错误修复版本需要保持二进制，源代码和序列化兼容性。
次要版本对于不同的项目意味着不同的东西，但通常它们不需要保持源代码兼容性。
主版本号可以打破所有三种forms。
我在这里写了更多关于这个理由的文章。
release.major.minor.revision会是我的猜测。
但是产品之间可能差别很大。
主要，次要，补丁，构build，安全补丁等的组合
前两个是主要和次要的 – 其余的将取决于项目，公司，有时是社区。 在FreeBSD这样的操作系统中，你将有1.9.0.1_number代表一个安全补丁。
取决于语言，Delphi和C＃有不同的含义。
通常情况下，前两个数字分别代表主版本和次版本，即第一个版本为1.0，一些重要的缺陷修正为1.1，次要新function为2.0，大型新function版本为2.0。
第三个数字可以指“真正轻微”的版本或修订。 例如1.0.1只是一个非常小的错误修正到1.0.0。 但是它也可以携带源代码pipe理系统的版本号，或者是一个随着版本的增加而递增的数字。 或者一个date戳。
这里稍微详细一点 。 在“.net”中，4个数字是“Major.Minor.Build.Revision”，而在Delphi中则是“Major.Minor.Release.Build”。 我为我的版本使用“Major.Minor.ReallyMinor.SubversionRev”。
一般来说，数字格式是version.major.minor.hotfix，而不是单个的内部组件。 所以v1.9.0.1将是版本1，主版本9（v1），次版本（v1.9）0，（v1.9.0）的热补丁1。
第一个数字通常被称为主版本号。 它基本上用来表示构build之间的重大变化（即，当您添加许多新function时，增加主要版本）。 来自同一产品的不同主要版本的组件可能不兼容。
下一个数字是次要版本号。 它可以代表一些新function，或者一些错误修复或者小的架构变化。 来自同一产品的小版本号的组件可能会或可能不会一起工作，可能不应该。
下一个通常被称为内部版本号。 这可能会每天增加，或每个“发布”构build，或每个构build。 两个组件之间可能只有很小的差异，这些组件之间的差别仅在于内部版本号，通常可以很好地协同工作。
最后一个数字通常是修订号码。 通常情况下，这被自动构build过程所使用，或者当您正在进行“一次性”丢弃构build以进行testing时。
当你增加你的版本号码取决于你，但他们应该始终增加或保持不变 。 您可以让所有组件共享相同的版本号，或者只更改已更改组件的版本号。
一个复杂的软件版本号代表整个软件包，并且与部件的版本号无关。 Gizmo版本3.2.5可能包含Foo版本1.2.0和Bar版本9.5.4。
在创build版本号时，请按如下所示使用它们：
-
第一个数字是主要版本。 如果您对用户界面进行了重大更改或需要打破现有界面（以便用户将不得不更改其界面代码），则应该转到新的主要版本。
-
第二个数字应该表明已经添加了新的function或者在内部有不同的function。 （例如，Oracle数据库可能会决定使用不同的策略来检索数据，使大多数事情变得更快，而且有些事情变慢。）现有的接口应该继续工作，用户界面应该是可识别的。
-
版本编号进一步取决于编写软件的人 – Oracle使用五个（！）组，即。 Oracle版本就像10.1.3.0.5。 从第三组开始，您只应该引入错误修正或function上的小改动。
软件构build过程的注意事项
那些变化较小的将是前两名，major.minor，之后可以是从构build，修订，发布到任何自定义algorithm（如某些MS产品）
每个组织/小组都有自己的标准。 重要的是你坚持你select的任何符号，否则你的客户会感到困惑。 说了我通常使用3个数字：
x.yz.bbbbb。 其中：x：主要版本（主要新function）y：是次要版本号（小的新function，没有UI更改的小改进）z：是Service Pack（基本上与xy相同，但有一些bug修复bbbb：是内部版本号，只有在“about box”和其他客户支持细节中才能看到，bbbb是自由格式，每个产品都可以使用它自己的格式。
这是我们使用的：
- 第一个数字=整个系统时代。 每两年更换一次，通常代表技术或客户端function或两者的根本性变化。
- 第二个数字=数据库模式修订。 这个数字的增加需要数据库迁移，所以是一个重要的变化（或者系统复制，所以改变数据库结构需要仔细的升级过程）。 如果第一个数字改变，则重置为0。
- 第三个数字=软件只能改变。 由于数据库模式不变，通常可以在客户端上按客户端实现。 如果第二个数字改变，则重置为零。
- Subversion版本号。 我们使用TortoiseSVN工具在构build时自动填充它。 这个数字不会重置，而是不断增加。 使用这个，我们总是可以重新创build任何版本。
这个系统为我们提供了很好的服务， 我已经看到其他的团队正在处理主要/次要问题（主要变化有多大），我看不出有什么好处。 如果你不需要跟踪数据库版本，只需要input一个3或2位的版本号码，让生活更轻松！
人们并不总是意识到2.1,2.0.1或2.10等版本号之间的细微差别 – 向技术支持人员询问他们遇到了多less麻烦。 开发人员注重细节，熟悉分层结构，所以这是我们的盲点。
如果可能的话，向客户公开一个更简单的版本号。
