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


107

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

就我个人而言,我更喜欢以十六进制表示的内部版本号(例如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.

Answers:


45

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

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

对于个人项目,我经常发现这是过大的。我曾在C#中搜索项目等大型项目中工作过几次,但我坚持使用该约定,并能够有效地将其用作内部跟踪器。


1
这倾向于遵循我在许多大型或小型项目中成功使用的模式。这是非常有效的。
luis.espinal

1
“内部版本号”与“变更集标识符(哈希)”有什么关系/应该如何?它是哈希,增量或其他内容的一部分吗?
杰斯·布朗宁

@Jace,在我工作的地方,我们使用Mercurial,然后删除变更集编号。我们只从单个存储库中推入/拉出,因此该号码并非特定结帐所独有。这样,我们便有了[major]。[minor]。[changeset](尽管自上一版本以来,主要编号和次要编号通常比指示进步的营销更多)。
Wai Ha Lee

如果在.NET版本结构上调用ToString(),则内部版本将是第3个数字,而不是修订版本。正如您在此powershell脚本中看到的:$version = New-Object System.Version 1, 2, 3, 4; $version.ToString(); $version.Build;
Joel McBeth

“内部版本号”是否暗示它只是一些小的调整,例如错误修复?是否应该有任何新功能至少获得其自己的修订号?
凯尔·德莱尼

90

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


惊讶的是没有得到更多的爱。
Mark Canlas 2012年

我参加聚会有点晚了...我在原始问题的9个月后添加了这个答案。;-)
M. Dudley

看起来这与我在下面提到的RubyGems Rational Versioning策略完全一样,只是形式化得更好。
肯·布鲁姆

@MarkCanlas不会获得更多的喜爱,因为它在构成主要/次要/补丁版本的内容上附加了特定的想法。它谈论的API有点...很奇怪
Rudolf Olah

5
SemVer适用于版本控制API,而不是面向用户的软件:“使用语义版本控制的软件必须声明公共API。” 因此,从技术上讲,没有公共API,您将无法使用SemVer。但是,采用与SemVer类似的方式对面向用户的应用程序进行版本控制可能很有意义。
Ajedi32

33

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

年,月,日,日构建

自我解释。


4
而且您始终知道您的代码有多新鲜。:)
Lipis 2010年

3
这也与Ubuntu的版本号相似。他们使用year.month示例:10.04和10.10
Brad Cupit 2010年

5
值得一提的是,这仅适用于不存在兼容性问题(网站)或固有地始终不兼容(ubuntu版本)的系统。
jkerian 2010年

1
@jkerian,为什么兼容性对此很重要?
AviD 2011年

12
@AviD:我对您为什么要问这个问题感到有些困惑,因为几乎所有其他回答都显示了包含兼容性信息的版本系统。您的选择取决于您要使用版本号记录的信息。就我的目的而言,日期基本上没有任何意义(仅从v1开始,增加每次构建都会有所改善)。你曾经分支吗?您有没有在发布“新版本”的同时发布“旧代码的新补丁”?但是对于诸如网站或操作系统之类的东西,基于日期的系统似乎非常合适。
jkerian 2011年


10

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

  • 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。用于发布分支

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

敏捷版本编号

PA表示pre-alpha A 表示alpha B 表示beta AR表示alpha释放 BR表示beta释放 RC表示释放候选 ST表示稳定

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

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

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

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

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

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


第一条链接关闭……
Pacerier

8

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

[病情] [替代动物名]

其中以“ Limp Lamprey ”,“ Wombed Wombat ”和“ Athmatic Anteater为名

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


2
似乎是时间和精力的低效使用........
Pacerier

10
因此,只好留下评论,但并没有阻止您。
Jesse C. Slicer 2015年

整体上来说要小得多……
Pacerier,2015年

7

Generation.Version.Revision.Build(9.99.999.9999)

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

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

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

构建是内部信息。


好主意。您从何处获得“一代”想法?
Pacerier 2015年

6

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

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

1.2.3-164-g6f10c

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

这样的好处是,您可以准确地知道自己是从哪个来源构建的,而不必自己为每个单独的构建编号。


2

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

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

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

主要,次要,修订版本

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

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

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

一切都与可追溯性有关!


1

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

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

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

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


1

版本号应具有足够的信息,可以避免冲突以及解决错误的发行类型问题中的错误,但不应传达不相关的其他信息。

例如,如果您使用日期,则客户可以告诉他们他们具有较旧的版本,而针对旧版本的补丁可能具有令人困惑的版本。

我个人喜欢语义版本控制

  • 版本是MajorMinorPatch
  • 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(至少在没有处理更改的情况下)。


Semver仅适用于API。不是产品。
Pacerier 2015年

@Pacerier您能解释为什么吗?
基思2015年


@Pacerier并不意味着您不能使用此模式进行版本编号。
基思

0
              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当我认为该应用程序具有一组非开发人员感兴趣的功能并且相对稳定时,我会创建一个新版本。这样,当有人问一个应用程序时,我可以演示该应用程序的“最新已知良好版本”的演示。在不久的将来,我计划Z在我们的Bugtracker中使用数字版本来命名功能的“目标”。

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.