it-swarm.cn

您使用什么“版本命名约定”?

不同的版本命名约定是否适合不同的项目?您使用什么,为什么?

就个人而言,我更喜欢以十六进制表示的内部版本号(例如11BCF),应该非常规律地增加此数量。然后为客户提供一个简单的3位数版本号,即1.1.3。

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.
111
rjstelling

我发现自己很少完全同意Jeff Atwood的观点,但是我倾向于遵循 他对.NET版本编号惯例的看法

(主要版本)。(次要版本)。(版本号)。(内部版本号)

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

47
Mike B

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

90
M. Dudley

我不使用它,但是我已经看到了,它是一个有趣的结构:

年,月,日,日构建

自我解释。

33
Maniero

我尝试使用 RubyGems Rational版本控制策略 ,其中:

  • 二进制兼容性损坏时,主要版本号增加
  • 添加新功能时,次要版本号增加
  • 内部版本号将针对错误修复进行更改。
14
Ken Bloom

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

  • N.x.K,其中NK是整数。示例:1.x.05.x.110.x.33。用于中间版本
  • N.M.K,其中NMK是整数。示例:1.0.05.3.110.22.33。用于发行
  • N.x.x,其中N是整数。例如:1.x.x。用于支持分支
  • N.M.x,其中NM是整数。例如:1.0.x。用于发布分支

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

Agile version numbering

PA表示pre-alphaA表示alphaB表示 betaAR表示alpha发行版BR表示beta发行版RC表示释放候选ST表示稳定

这种版本编号方法的优点如下:

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

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

我个人对使用日期版本而不是实际版本号的态度是假设软件开发人员使用的是过时的版本:

  • 对软件开发生命周期一无所知。开发通常是敏捷和迭代的。版本编号方法应代表软件开发过程的迭代性质。
  • 不在乎软件质量。质量控制和保证是敏捷和迭代的。就像发展一样。版本号应该是开发和质量控制/保证的敏捷和迭代性质的证明。
  • 不在乎其应用程序的体系结构idea。主版本号(N.M.K中的N)负责体系结构解决方案和应用程序的基本原理。主要版本号N将根据体系结构的更改或其工作/功能的主要思想和原则的更改而进行更改。
  • 无法控制其代码库。大概只有一个分支(主干),它用于所有内容。我个人认为这不对,因为它鼓励代码库成为一个大型垃圾场。

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

10
altern

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

[病情] [替代动物名]

其中的名称为“ Limp Lamprey“,“ 受伤的袋熊”和“ 哮喘食蚁兽”。

确保除非它是一个很酷的名称,否则它不会泄漏给您的客户。

8
Jesse C. Slicer

Generation.Version.Revision.Build(9.99.999.9999)

世代很少改变。只需打开一个大的产品:DOS-> Windows,即可完成重新设计。

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

经常进行修订(较小的功能和错误修复)。

构建是内部信息。

7
Maniero

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

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

1.2.3-164-g6f10c

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

这样做的好处是,让您知道完全您是从哪个来源构建的,而不必自己为每个单独的构建编号。

6
Cascabel

我更喜欢分配一些语义的版本号。只要您可以使用版本号来跟踪特定版本报告的错误以对源代码(以及活动管理系统)中发生的更改进行跟踪,那么您就可能使用了正确的方法。

我使用.NET,所以我仍然使用.NET版本编号系统,但是我尝试赋予数字以语义含义,因此

主要,次要版本,修订版本

  • 专业=(取决于项目)
  • 次要=(取决于项目)
  • build = Hudson的内部版本号(您可以在此处使用TeamCity或TeamBuild等)
  • 版本= Subversion或Bazaar版本(取决于项目及其用途)

我们始终确保以某种方式显示版本号(使用基于控制台的批处理程序将其打印到控制台,并显示日志文件,通常在顶部的菜单栏中显示网络应用)

这样,如果客户报告问题,我们可以使用版本号来跟踪他们是否正在使用最新版本以及特定版本中遇到了多少问题。

一切都与可追溯性有关!

2
Jeffrey Cameron

Major.Minor.Public(内部)[alpha/beta/trial],例如“ 4.08c(1290)”

  • 以Major为主要版本号(1、2、3 ...)
  • 次要版本是2位数的次要版本(01、02、03 ...)。通常,当添加了重要的新功能(仅用于错误修复)时,十位数会递增。
  • Public是构建版本(a,b,c,d,e)的公共版本,如果从未将次版本作为公共更新发布,则通常与次版本不同。
  • 内部版本号,即编译器跟踪的实际内部版本号。
  • 对于这些特殊情况,请附加TRIAL,ALPHA,BETA X或RCX。
2
GrandmasterB

我们使用Major.Minor.Build#.YYMMDD [后缀],因为我们通常只在特定的一天进行一次生产构建(但如果有多个,则使用ab/c/d后缀),并且YYMMDD可以为用户/客户/管理人员提供内部版本的指示,而6.3.1389则没有。

主要产品数量随着重要产品功能(付费)的增加而增加。

次要数字随着修复/改进(免费更新)而增加。

建造总是在增加;并非所有的建造都可以交付,所以它不是线性发展。

1
JBRWilkinson
 1.0.0 
 | 
 1.0.1 
 | 
(公共1.0)1.0.2 ----- 
 |\
 2.0.0 1.1.0 
 | | 
 2.0.1 1.1.1(公共1.1)
 | 
(公共2.0)2.0.2 ----- 
 |\
 3.0.0 2.1.0 
 | 
 2.1.1(公共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_之间的任何版本)。

0
barjak