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

解决方案

回答

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

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

回答

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

回答

major.minor [.maintenance [.build]]

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

回答

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

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

干杯

回答

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

回答

在1.9.0.1版中：

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

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

回答

通常是：

MajorVersion.MinorVersion.Revision.Build

回答

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

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

回答

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

回答

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

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

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

回答

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

例如，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.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是程序的一项更改，该更改或者破坏了旧功能，或者太大，以某种方式改变了用户应如何使用该程序。

回答

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

回答

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

回答

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

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

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

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

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

回答

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

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

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

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

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

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

回答

从CAssemblyInfo.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.

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

• 第一个数字是主要版本。如果我们对用户界面进行了重大更改或者需要中断现有界面(以便用户必须更改其界面代码)，则应使用新的主版本。
• 第二个数字应表示已添加新功能或者内部某些功能不同。 (例如，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位数字的版本号即可，使工作更轻松！

回答

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

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

回答

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

回答

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

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

回答

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

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

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

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

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