文章
文章文档网址导航

推荐的移动应用的版本名称管理规范

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

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

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

我们先看看国内和国外知名互联网公司 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 系统版本:
-------------------------------------------------------------------------------------
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 系统版本:
-------------------------------------------------------------------------------------
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

我们统计下相关的版本所占比例：

移动应用不同版本类型占比

不用多说，我们就知道了应该更倾向于采用哪种版本名称的格式：版本名称格式: x.x.x

我们把 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.flygoly.demo"
    android:versionCode="1"
    android:versionName="1.0.0" >

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

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

</manifest>
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.flygoly.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 工程，然后我们来查看默认的版本标注：

iOS App 默认 Version 和 Build

以上事情是不是说明 Apple 有点自己打自己脸的意思呢？你官方 API 说明中给出的版本标注格式和你自己 Xcode 中创建项目的默认版本标注格式还不一样？

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

另外有几点觉得可以给出一些个人的看法：

  • 一般公司的应用版本的发布是由相关运营人员专门去管理的，一般也不是开发人员亲自发布。我们现在常用的版本对比的机制是：
    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 文件中载入这两个值就好了，为什么要为了解决一个本来就不应该这么做的事情，而去违背规则的本身呢？
  • 有些公司将 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 分开表述的意义了。
  • 还有些公司将 android:versionName/iOS:Bundle Versions String 写成如下格式：
    x.x.x.Date:1.1.3.19980520
    如果以上日期相对于当前时间过去很久的话，用户会不会觉得你这个应用这么久了还不更新，是不是会觉得你的应用很旧了呢？
  • 有些公司为了哗众取宠或者引起用户的注意，不断的推出新的版本，甚至在没有什么大的变化的情况下，修改主版本号，这样都是不可取的。

关于语义化版本管理的个人理解：

  • x.y.z 中，x 是主版本号，y 是次版本号，z 是修订号
  • x.y.z 中，x 表示大版本更新，y 表示新增/修改一些功能模块，z 表示修复 Bug
  • 如果没有发布第一个正式版本，那么我们的主版本号永远为 0，例如：0.y.z
  • 第一个非正式的版本，一般默认版本号：0.1.0，第一个正式版本，版本号为：1.0.0
  • 当主版本号变化时，次版本号和修订号都要归零
  • 当次版本号变化时，修订号要归零
  • 一般来说发布到市场的正式版本，都是 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
  • 一般来说，除非是修订 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 常见
  • 无论版本号怎么变化，只要版本号变化了，Build 号一定要 +1

如果觉得文章对你有帮助，欢迎赞赏支持

如果觉得文章对你有帮助，欢迎赞赏支持
博客

使用 TestFlight 进行 iOS App 内测

2020-6-15 14:51:00

博客

关于物联网行业的一点浅见

2022-7-14 17:53:00

❯
搜索

  • 扫码打开当前页

返回顶部