推荐的移动应用的版本名称管理规范 2020-08-19 / 8,098 次 / 3 条 /

android:versionCode/Bundle Version:CFBundleVersion:Build 和
android:versionName/iOS:Bundle Versions String , Short:CFBundleShortVersionString:Version
推荐的命名规范

最近负责公司软件版本规范,首要处理的是软件版本名称的问题,发现之前遗留的软件版本名称的管理存在较大问题,需要做一个详细的总结,为公司的软件开发的版本管理做统一规范。

可能遇到这个问题的时候,我们解决问题的方式是:先查找相关的版本名称管理规范,然后去执行就行。是的,我们可以这样。但是,现在有不止唯一的版本名称管理规范,尽管大的规范都是类似的,但是小的细节上不尽相同,我们要去思考的是这些小的细节,为什是这样,哪些适合我们,哪些不适合。这样我们才能深刻理解版本名称管理规范,并且严格执行。好的规范,都是能够很大程度的让工作有序,并且高效,避免差错,被大家所认同。

我们今天换一种思考解决问题的方式:首先我们不去查看相关的软件版本名称规范,我们先看看大公司的软件版本名称格式是怎么样的。

我们先看看国内和国外知名互联网公司 Android 的应用:

Android 应用版本格式

-------------------------------------------------------------------------------------
国内知名互联网公司
-------------------------------------------------------------------------------------
腾讯
QQ:
5.6.1
微信:
6.1.0.76_r1119377

百度
百度地图:
8.2.5

阿里巴巴
淘宝:
5.2.8
支付宝钱包:
8.6.0.040305

360
360安全卫士:
6.1.6
360安全浏览器:
6.9.7

搜狐
搜狐新闻:
5.2.0
搜狗输入法:
7.5.2

新浪
新浪微博:
5.1.2

网易
有道云笔记:
4.4.1
网易邮箱:
3.8.7

小米
小米桌面:
3.7.0

京东
京东:
4.2.0

优酷
优酷视频:
4.7.5

人人
人人网:
8.0.0

我叫MT 2:
1.7.6.0

刀塔传奇:
2.1.3

天天酷跑:
1.0.21.0Build478

-------------------------------------------------------------------------------------
国外知名互联网公司
-------------------------------------------------------------------------------------

Facebook
Facebook Client:
35.0.0.0.250
Facebook Messenger:
29.0.0.3.279

Yahoo
Yahoo Weather:
1.3.6

Google
Google Maps:
9.9.0

Twitter
Twitter:
5.57.0

Pinterest
pinterest:
4.7.1

Snapchat
Snapchat:
9.7.5.0

WhatsApp
WhatsApp Messenger:
2.12.96

Pandora
Pandora Radio:
1.4.5

Instagram
Instagram:
6.22.0

Skype
Skype:
5.3.99.65524
然后再看看国内和国外知名互联网公司 iOS 的应用:
iOS 应用版本格式

-------------------------------------------------------------------------------------
国内知名互联网公司
-------------------------------------------------------------------------------------
腾讯
QQ:
5.5.1
微信:
6.2.0

百度
百度地图:
8.2.5

阿里巴巴
淘宝:
5.2.7
支付宝钱包:
8.6.4.051102

360
360安全卫士:
4.5.0
360安全浏览器:
2.1.2

搜狐
搜狐新闻:
5.1.0
搜狗输入法:
3.0.0

新浪
新浪微博:
5.3.0

网易
有道云笔记:
4.3.1
网易邮箱:
3.9.4

小米
小米路由器:
1.9.0

京东
京东:
4.2.0

优酷
优酷视频:
4.5

人人
人人网:
8.0.1

我叫MT 2:
1.7.6

刀塔传奇:
3.2.7

天天酷跑:
1.0.21.0

-------------------------------------------------------------------------------------
国外知名互联网公司
-------------------------------------------------------------------------------------

Facebook
Facebook Client:
31.0
Facebook Messenger:
28.1

Yahoo
Yahoo Weather:
1.7.1

Google
Google Maps:
4.6.0

Twitter
Twitter:
6.28.1

Pinterest
pinterest:
4.7.2

Snapchat
Snapchat:
9.8.0

WhatsApp
WhatsApp Messenger:
2.12.2

Pandora
Pandora Radio:
Unkown

Instagram
Instagram:
6.12.0

Skype
Skype:
4.18.1
-------------------------------------------------------------------------------------
Android 系统版本:
-------------------------------------------------------------------------------------
Android 1.0
Android 1.1
Android 1.5
Android 1.6
Android 2.0
Android 2.0.1
Android 2.1
Android 2.2
Android 2.2.1
Android 2.2.2
Android 2.2.3
Android 2.3
Android 2.3.1
Android 2.3.2
Android 2.3.3
Android 2.3.4
Android 2.3.5
Android 2.3.6
Android 2.3.7
Android 3.0
Android 3.1
Android 3.2.1
Android 3.2.2
Android 3.2.3
Android 3.2.4
Android 3.2.5
Android 3.2.6
Android 4.0
Android 4.0.1
Android 4.0.2
Android 4.0.3
Android 4.0.4
Android 4.1
Android 4.1.1
Android 4.1.2
Android 4.2
Android 4.2.1
Android 4.2.2
Android 4.3
Android 4.3.1
Android 4.4
Android 4.4.1
Android 4.4.2
Android 4.4.3
Android 4.4.4
Android 4.4W.1
Android 4.4W.2
Android 5.0
Android 5.0.1
Android 5.0.2
Android 5.1
Android 5.1.1
-------------------------------------------------------------------------------------
iOS 系统典型版本:
-------------------------------------------------------------------------------------
iOS 3.1.3
iOS 4.2.1
iOS 5.1.1
iOS 6.1.6
iOS 7.1.2
iOS 8.0
iOS 8.0.1
iOS 8.0.2
iOS 8.1
iOS 8.1.1
iOS 8.1.2
iOS 8.1.3
iOS 8.2
iOS 8.3

recommended-mobile-application-version-name-management-specification-popular-apps-version-style

不用多说,我们就知道了应该更倾向于采用哪种版本名称的格式:
版本名称格式: x.x.x
iOS 关于版本名称的官方文档说明:
原文版本:
Bundle Version 与 Bundle Versions String , Short 的说明:
https://developer.apple.com/library/ios/documentation/General/Reference/InfoPlist
KeyReference/Articles/CoreFoundationKeys.html

中文版本:
Bundle Version:CFBundleVersion
CFBundleVersion (String – iOS, OS X) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle. The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero. The string should only contain numeric (0-9) and period (.) characters. Leading zeros are truncated from each integer and will be ignored (that is, 1.02.3 is equivalent to 1.2.3). This key is not localizable.
指定 Bundle 的编译版本数,用来标识 Bundle 的迭代(正式发布或非正式发布)。编译版本数应当是一个包含3个非负,点号间隔的整数,并且第一个整数需要大于0。这个字符串仅能包含 0-9和”.”间隔。每一个整数前置的0会被忽略掉(比如:1.02.3 等同于 1.2.3)。此键非本地化。
Bundle Versions String , Short:CFBundleShortVersionString
CFBundleShortVersionString (String – iOS, OS X) specifies the release version number of the bundle, which identifies a released iteration of the app. The release version number is a string comprised of three period-separated integers. The first integer represents major revisions to the app, such as revisions that implement new features or major changes. The second integer denotes revisions that implement less prominent features. The third integer represents maintenance releases.
指定 Bundle 的发布版本数,用来标识应用的发布迭代。发布版本数是一个包含3个间隔的整数的字符串。第一个整数表示应用的主要的修改。例如:实现新的特性或者主要的变化。第二个整数表示实现了较突出的特性。第三个整数表示维护版本。
The value for this key differs from the value for CFBundleVersion, which identifies an iteration (released or unreleased) of the app. This key can be localized by including it in your InfoPlist.strings files.
这个键对应的值与 CFBundleVersion 对应的值是有区别的。这个键能够本地化,并且引入到你的 InfoPlist.strings 文件中。
我们把 Android 和 iOS 应用的版本标注格式对比如下:
ADT Bundle:AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.ifeegoo.demo"
    android:versionCode="1"
    android:versionName="1.0.0" >

    <uses-sdk
        android:minSdkVersion="8"
        android:targetSdkVersion="19" />

    <application android:allowBackup="true" >
    </application>

</manifest>
Android Studio:build.gradle

apply plugin: 'com.android.application'

android {
    compileSdkVersion 22
    buildToolsVersion "22.0.1"

    defaultConfig {
        applicationId "com.ifeegoo.demo"
        minSdkVersion 15
        targetSdkVersion 22
        versionCode 1
        versionName "1.0.0"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}
iOS Xcode:Info.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleDevelopmentRegion</key>
	<string>en</string>
	<key>CFBundleExecutable</key>
	<string>$(EXECUTABLE_NAME)</string>
	<key>CFBundleIdentifier</key>
	<string>com.ifeegoo.demo</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleName</key>
	<string>$(PRODUCT_NAME)</string>
	<key>CFBundlePackageType</key>
	<string>APPL</string>
	<key>CFBundleShortVersionString</key>
	<string>1.0.0</string>
	<key>CFBundleSignature</key>
	<string>????</string>
	<key>CFBundleVersion</key>
	<string>1.0.0</string>
	<key>LSRequiresIPhoneOS</key>
	<true/>
	<key>UILaunchStoryboardName</key>
	<string>LaunchScreen</string>
	<key>UIMainStoryboardFile</key>
	<string>Main</string>
	<key>UIRequiredDeviceCapabilities</key>
	<array>
		<string>armv7</string>
	</array>
	<key>UISupportedInterfaceOrientations~ipad</key>
	<array>
		<string>UIInterfaceOrientationPortrait</string>
		<string>UIInterfaceOrientationPortraitUpsideDown</string>
		<string>UIInterfaceOrientationLandscapeLeft</string>
		<string>UIInterfaceOrientationLandscapeRight</string>
	</array>
</dict>
</plist>
我们可以对比认为:
android:versionCode 等同于 iOS:Bundle Version:CFBundleVersion:Build
android:versionName 等同于 iOS:Bundle Versions String , Short:CFBundleShortVersionString:Version
虽然 android:versionName 和 iOS:Bundle Versions String , Short:CFBundleShortVersionString:Version 都可以用 1.0.0 这样的格式来表示。但是我们发现 android:versionCode 和 iOS:Bundle Version:CFBundleVersion:Build 官方描述的格式完全不同!Android的版本描述是完全可以被接受的,但是 iOS 对于 Bundle Version:CFBundleVersion:Build 的官方描叙让人很难理解。我们先看一个东西,我用 Xcode Version 6.3.2 (6D2105) 创建一个 iOS 工程,然后我们来查看默认的版本标注:
recommended-mobile-application-version-name-management-specification-ios-default-verison-and-build
以上事情是不是说明 Apple 有点自己打自己脸的意思呢?你官方 API 说明中给出的版本标注格式和你自己 Xcode 中创建项目的默认版本标注格式还不一样?

我们且不去追究 Apple 的问题,对于以上内容的分析,我们可以定义一个自己的推荐性的版本标注规范了:

Android:
android:versionCode
说明:大于0的整数。从1开始,每发布一个版本(无论内测版本还是正式版本),每次 +1。
android:versionName
说明:格式为 x.x.x,x 为非负整数。从 0.0.1 开始,内测版本保持 0.x.x 格式。正式版本从 1.0.0 开始。正式版本一般是从开始正式对外发布的第一个版本算起。
第一位整数:表示大的版本的迭代。例如:整体 UI 框架和功能大的变化。
第二位整数:表示部分功能或其它的较大变化。例如:增加了数据同步功能。
第三位整数:表示版本的维护。例如:UI 的微调,bug 的修复。
备注:
1.当第一位变动的时候,第二位和第三位要置0,当第二位变动的时候,第三位要置0!另外禁止在整数之前加0,例如:1.03.09 这种格式是禁止的!例如:当前为1.1.13版本,修改了整体UI框架。那么下一个版本为:2.0.0版本。当前为1.0.13版本,增加了部分功能,那么下一个版本为1.1.0版本。
2.一般来说,不管是应用还是库工程,如果你第一个内测版本是完成了较多功能的,推荐采用0.1.0作为第一个版本。如果只是一些很少功能的完成,推荐采用0.0.1作为第一个版本。
iOS:
Bundle Version:CFBundleVersion:Build
说明:大于0的整数。从1开始,每发布一个版本(无论内测版本还是正式版本),每次 +1。
iOS:Bundle Versions String , Short:CFBundleShortVersionString:Version
说明:格式为 x.x.x,x 为非负整数。从 0.0.1 开始,内测版本保持 0.x.x 格式。正式版本从 1.0.0 开始。正式版本一般是从开始正式对外发布的第一个版本算起。
第一位整数:表示大的版本的迭代。例如:整体 UI 框架和功能大的变化。
第二位整数:表示部分功能或其它的较大变化。例如:增加了数据同步功能。
第三位整数:表示版本的维护。例如:UI 的微调,bug 的修复。
备注:
1.当第一位变动的时候,第二位和第三位要置0,当第二位变动的时候,第三位要置0!另外禁止在整数之前加0,例如:1.03.09 这种格式是禁止的!例如:当前为1.1.13版本,修改了整体UI框架。那么下一个版本为:2.0.0版本。当前为1.0.13版本,增加了部分功能,那么下一个版本为1.1.0版本。
2.一般来说,不管是应用还是库工程,如果你第一个内测版本是完成了较多功能的,推荐采用0.1.0作为第一个版本。如果只是一些很少功能的完成,推荐采用0.0.1作为第一个版本。
我们以上推荐的规范可以参见:
Semantic Versioning / 语义化版本
官方网站:http://semver.org/
说明:语义化版本控制的规范是由 Gravatars 创办者兼 GitHub 共同创办者 Tom Preston-Werner 所建立的推荐性的版本控制规范。
另外有几点觉得可以给出一些个人的看法:
1.一般公司的应用版本的发布是由相关运营人员专门去管理的,一般也不是开发人员亲自发布。我们现在常用的版本对比的机制是:
Android 中对比 android:versionCode 的值
iOS 中对比 Bundle Version:CFBundleVersion:Build 的值
说明:目前 iOS 的应用,如果你将自己的应用发布到 App Store 上,那么在你的应用内部是不能包含版本更新的东西的(App Store 已经明确的说明了这一点,为了不让用户迷惑,统一由 App Store 来推送版本)。你只能在非 App Store 发布版本中去推送更新。
通常开发人员在提供应用安装包的时候,只附带了一个 android:versionName/iOS:Bundle Versions String , Short:CFBundleShortVersionString:Version,例如 1.1.3,那么运营人员还是需要在后台去填写 android:versionCode/Bundle Version:CFBundleVersion:Build 的值,有些人就制定了以下规则:
android:versionName/iOS:Bundle Versions String:1.03
android:versionCode/Bundle Version:CFBundleVersion:Build –> 103
为了方便运营人员在后台填写相关信息。我觉得这样完全是不可接受的,首先,1.03这种格式我是不太认同的,同时,如果你从1.00开始,那么之前的 1-99次的版本发布哪里去了?既然你开发人员发提供安装包的时候,为什么不一起提供这两个值呢?而且好像直接从一个 .apk/.ipa 文件也看不出来这两个值吧。或者你后台技术能力强点,你直接从 .apk/.ipa 文件中载入这两个值就好了,为什么要为了解决一个本来就不应该这么做的事情,而去违背规则的本身呢?
2.有些公司将 android:versionName/iOS:Bundle Versions String 写成如下格式:
x.x.x.(android:versionCode/Bundle Version:CFBundleVersion:Build):2.3.4.157
我觉的这样违背了 android:versionName/iOS:Bundle Versions String 与 android:versionCode/Bundle Version:CFBundleVersion:Build 分开表述的意义了。
3.还有些公司将 android:versionName/iOS:Bundle Versions String 写成如下格式:
x.x.x.Date:1.1.3.19980520
如果以上日期相对于当前时间过去很久的话,用户会不会觉得你这个应用这么久了还不更新,是不是会觉得你的应用很旧了呢?
4.有些公司为了哗众取宠或者引起用户的注意,不断的推出新的版本,甚至在没有什么大的变化的情况下,修改主版本号,这样都是不可取的。

追加内容:
1.x.y.z 中,x 是主版本号,y 是次版本号,z 是修订号。
2.x.y.z 中,x 表示大版本更新,y 表示新增/修改一些功能模块,z 表示修复 Bug。
3.如果没有发布第一个正式版本,那么我们的主版本号永远为 0,例如:0.y.z。
4.第一个非正式的版本,一般默认版本号:0.1.0,第一个正式版本,版本号为:1.0.0。
5.当主版本号变化时,次版本号和修订号都要归零。
6.当次版本号变化时,修订号要归零。
7.一般来说发布到市场的正式版本,都是 x.y.z x > 0 的形式,如果有内测版本,一般采取 x.y.z-pre-alpha/x.y.z-alpha/x.y.z-beta/x.y.z-rc 形式来命名,当然如果 pre-alpha/alpha/beta/rc 阶段有多个版本,我们就命名成这种形式:x.y.z-pre-alpha.13/x.y.z-alpha.14/x.y.z-beta.15/x.y.z-rc.16。
8.一般来说,除非是修订 Bug,这种情况下 x.y.z z 不断的 +1。否则的话,版本的发布会由项目经理和产品经理约定一个版本号,一般是指明 x.y.z 中的 x 和 y,比如指定下一个版本为 2.0.0 或者 3.2.0,就以指定 3.2.0 版本为例子:目前产品的版本为 3.1.0,假若内部确定没有到 3.2.0 版本不要发布,那么如果刚开始只是迭代Bug,那就是 3.1.z,修订号 z 不断的 +1,一旦是说要去测试或者内部推动 3.2.0 版本的时候,我们要根据以下情况来区分版本标记:
pre-alpha:功能不完整的阶段。
alpha:版本仍然需要测试,其功能亦未完善,版本通常会送到开发软件的组织或某群体中的软件测试者作内部测试。在市场上,越来越多公司会邀请外部客户或合作伙伴参与其测试。这令软件在此阶段有更大的可用性测试。在测试的第一个阶段中,开发者通常会进行白盒测试。其他测试会在稍后时间由其他测试团体以黑盒或灰盒技术进行,不过有时会同时进行。
beta:版本是软件最早对外公开的软件版本,由公众(通常为公司外的第三方开发者和业余玩家)参与测试。一般来说,Beta 包含所有功能,但可能有一些已知问题和较轻微的程序错误(BUG),要进行调试(debug)。Beta版本的测试者通常是开发软件的组织的客户,他们会以免费或优惠价钱得到软件。Beta 版本亦作为测试产品的支持和市场反应等。
rc:Release Candidate(简称RC)指可能成为最终产品的候选版本,如果未出现问题则可发布成为正式版本。在此阶段的产品通常包含所有功能、或接近完整,亦不会出现严重问题。
由于语义化版本规范里面并没有针对这块有详细的规范建议,所以我这里推荐一个处理方式:一旦是说要去测试或者内部推动 3.2.0 版本的时候,依据以上不同阶段,我们将版本号标记成:
3.2.0-pre-alpha
3.2.0-alpha
3.2.0-beta
3.2.0-rc
如果每个阶段又有不同的版本,那么就结尾 +1:
3.2.0-pre-alpha.1
3.2.0-alpha.5
3.2.0-beta.3
3.2.0-rc.2
特别是当应用进入到 beta 和 rc 阶段的时候,我们可以通过后面的 +1 标记来判断开发或者测试是否是在发布正式版本前,还迭代了多少版本,版本越多,说明前期的开发和测试必然会存在问题,一般到 rc 阶段,可能就只有最多不超过 5 次 rc,一般 rc 为 2/3 常见。
9.无论版本号怎么变化,只要版本号变化了,Build 号一定要 +1。

打赏
本博客所有文章如无特别注明均为原创。复制或转载请以超链接形式注明转自ifeegoo,原文地址《推荐的移动应用的版本名称管理规范
上一篇: « 下一篇: »
Copyright © ifeegoo Time is limited, less is more! / 粤ICP备15109713号 / Theme by Hang & Ben / WordPress / 知识共享许可协议