您使用什么“版本命名约定”？ [关闭]

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

#1 楼

我倾向于遵循Jeff Atwood的.NET版本编号约定。

（主要版本）（次要版本）（修订版）（内部版本号）

对于个人项目，我经常发现这是过大的。几次我在诸如C＃的搜索引擎等大型项目中工作时，我一直坚持这一约定，并且能够有效地将其用作内部跟踪程序。

#2 楼

语义版本控制（http://semver.org/）在这里值得一提。它是版本控制方案的公共规范，形式为[Major].[Minor].[Patch]。此方案的动机是用版本号传达含义。

#3 楼

我没有使用它，但是我已经看到了，它是一个有趣的结构：

Year.Month.Day.Build

自我解释。

#4 楼

我尝试使用RubyGems Rational Versioning策略，其中：


破坏二进制兼容性时，主要版本号递增
添加新功能时，次要版本号递增
内部版本号已更改，用于错误修复。

#5 楼

这是非常细粒度的版本编号方法：



N.x.K，其中N和K是整数。示例：1.x.0，5.x.1，10.x.33。用于中间版本。

N.M.K，其中N，M和K是整数。示例：1.0.0，5.3.1，10.22.33。用于发布。

N.x.x，其中N是整数。例如：1.x.x。用于支持分支。

N.M.x，其中N和M是整数。例如：1.0.x。用于发布分支。

这是用于简单地说明版本编号方法的图片：



PA表示pre-alpha
A表示alpha
B表示beta
AR表示alpha发行版
BR表示beta发行版
RC表示候选发行版
ST表示稳定

/>这种版本编号方法的优点如下：


它代表了敏捷软件开发生命周期的细节。
它考虑了源代码存储库结构的细节。 >对于那些习惯了模式的人来说，这是自我解释。每个模式代表不同的工件。这样的模式可以很容易地解析并用于其他目的，例如问题跟踪。
版本模式集是描述版本控制方法的基础，可以用于收集度量标准和计划。
它着重于成熟度和质量水平的概念。通常，在没有太多必要的情况下分配了1.0.0这样的版本号（当软件为深Alpha版本时）。提出的版本编号方法允许建立多个成熟度级别。在最简单的情况下，它将只有两个级别：中间版本（N.x.K）和发布（N.M.K）。发布意味着具有完整版本号（N.M.K）的软件已经在供应商公司/组织/团队中经历了某种质量管理流程。
这表明开发和测试都具有敏捷性。
/>鼓励对软件结构和体系结构采用模块化方法。

还有更复杂的图，详细表示了版本控制方法。此外，您可能会找到有用的演示幻灯片，它们描述了向版本控制方法的过渡，以及SCMFViz应用程序，说明了版本编号方法的基本原理。演示幻灯片还解释了为什么在软件项目的整个生命周期中坚持相同的版本控制方法很重要。

我个人对使用日期版本而不是实际版本号的态度是假定软件开发人员带有过期版本的软件：



对软件开发生命周期一无所知。开发通常是敏捷和迭代的。版本编号方法应代表软件开发过程的迭代性质。

不在乎软件质量。质量控制和保证是敏捷和迭代的。就像发展一样。版本号应该是开发和质量控制/保证都具有敏捷性和迭代性的证据。

不在乎其体系结构或应用概念。主版本号（N中的N.M.K）既负责体系结构解决方案，又负责应用程序的基本原理。应当根据体系结构的更改或工作/功能的主要思想和原理的更改来更改主要版本号N。

不能控制其代码库。大概只有一个分支（主干），它用于所有内容。我个人认为不对，因为它会鼓励代码库成为一个大的垃圾场。

这种方法似乎有点争议，但是我相信这是为软件提供适当版本的最直接方法数字。

#6 楼

对于您发布的每个主要版本，在内部都将其称为有效版本并不少见。例如，在我的上一份工作中，我们使用了受Ubuntu启发的以下命名约定来引用主要版本：

[病情] [替代动物名]

例如“ Limp Lamprey”，“受伤的袋熊”和“哮喘食蚁兽”之类的名字。

请确保除非它是一个真正酷的名字，否则它不会泄漏给您的客户。

#7 楼

Generation.Version.Revision.Build（9.99.999.9999）

生成很少更改。只有一个大的产品：DOS-> Windows，完全重新设计。

版本用于不兼容的大更改，新功能，软件上某些特定范例的更改等。

经常进行修订（次要功能和错误修复）。

内部信息是内部信息。

#8 楼

git describe为您选择的任何编号约定提供了很好的扩展。将其嵌入到构建/打包/部署过程中很容易。

假设您将标记的发行版本命名为A.B.C（major.minor.maintenance）。给定提交上的git describe将找到该提交的最新标记祖先，然后添加此后的提交数量，以及提交的缩写SHA1：

1.2.3-164-g6f10c

当然，如果您实际上使用的是其中一个版本，则只需获取标记（1.2.3）。

这有一个很好的好处，那就是让您确切地知道构建的源来自，而不必自己编号每个建筑。

#9 楼

Major.Minor.Public（内部版本）[alpha / beta / trial]，例如“ 4.08c（1290）”


，其中Major为主要版本号（1、2、3 ...）
次要版本是2位数的次要版本（01、02、03 ...）。通常，当添加了重要的新功能时，十位数会递增，这些功能仅用于漏洞修复。
公共版本是版本的公共发行版（a，b，c，d，e），通常与次版本，如果次版本从不作为公共更新版本发布，则为
，是编译器跟踪的实际内部版本号。
在特殊版本后附加TRIAL，ALPHA，BETA X或RC X案例。

#10 楼

我更喜欢分配一些语义的版本号。只要您可以使用版本号来跟踪特定版本报告的错误以对源代码（以及活动管理系统）中发生的更改进行跟踪，那么您就可能使用了正确的方法。 >我使用.NET，所以我坚持使用.NET版本编号系统，但是我尝试使用数字赋予语义，以便使用

major.minor.build.revision


主要=（取决于项目）
次要=
（取决于项目）
Hudson的编号（您可以使用
此处为TeamCity或TeamBuild等）
版本=颠覆或集市
版本（取决于项目
及其用途）

我们始终确保版本号以某种方式可见（使用基于批处理控制台的程序将其打印到控制台和日志文件，通常在顶部的菜单栏中显示Web应用程序）

客户报告问题，我们可以使用版本号来跟踪他们是否使用最新版本版本以及我们在使用特定版本时遇到了多少问题。

所有与可追溯性有关！

#11 楼

我们使用Major.Minor.Build＃.YYMMDD [suffix]，因为我们通常只在特定的一天进行一次生产构建（但如果有多个，则使用ab / c / d后缀），而YYMMDD则为用户/客户/管理指示构建的年龄，而6.3.1389则没有。

随着重要的产品功能（付费），主要数量增加。

随着修复，次要数量增加。 / improvements（免费更新）。

构建总是在增加；并非所有建造都可以交付，所以它不是线性的。

#12 楼

版本号应具有足够的信息，可以避免冲突以及在错误的发行类型问题中解决错误，但不应传达不相关的其他信息。例如，如果您使用日期客户可以告诉他们它们具有较旧的版本，而针对旧版本的补丁可能具有令人困惑的版本。

我个人喜欢语义版本控制：



发布是Major。 Minor。 Patch


Patch每次发布版本都会递增。

Minor每次添加向后兼容功能都会递增。

Major递增当新功能不向后兼容时。
当Major == 0时，您处于Alpha /预发行版本中。 Major> = 1是您的公开发行版。
每次增加，较低的数字都会重置为0，因此


1.5.3-> 1.5.4（错误修复）-> 1.6.0（次要功能） ）-> 2.0.0（重大更改）



这样，如果有人使用例如1.5.3版本，他们可以一目了然地告诉他们可以升级到1.5.4以获取补丁程序中，1.6.0将添加功能，并且不应升级到2.0.0（至少在不处理更改的情况下）。

#13 楼

              1.0.0
                |
              1.0.1
                |
(public 1.0)  1.0.2-----
                |       \
              2.0.0    1.1.0
                |        |
              2.0.1    1.1.1 (public 1.1)
                |
(public 2.0)  2.0.2-----
                |       \
              3.0.0    2.1.0
                         |
                       2.1.1 (public 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Z是我们的内部版本号。 X.Y是公开版本号，对我们的客户有意义。当X.Y.Z版本公开时，将永远不会有X.Y.(Z+1)版本：公开版本始终是该系列的最后一个。

当发布主要版本时，X会递增。

Y用于那些主要版本的维护分支，仅用于错误修复。

Z在内部使用，没有固定含义。到现在为止，当我认为该应用程序具有一些非开发人员感兴趣的功能并且相对稳定时，我会创建一个新的Z版本。这样，当有人问一个应用程序时，我可以演示该应用程序的“最新已知良好版本”演示。在不久的将来，我计划在我们的bugtracker中使用Z数字版本来命名功能的“目标”。

作为附带说明，我们使用maven（与release命令一起）进行增量版本号。因此，也有X.Y.Z-SNAPSHOT版本（表示X.Y.(Z-1)和X.Y.Z之间的任何版本）。