如何设计 App 的版本号？

[Totato5749]

看了些文章，一般都是将软件版本号设计为 [主版本号.次版本号.修订号] 的形式

譬如某文章内提到：

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改， 次版本号：当你做了向下兼容的功能性新增， 修订号：当你做了向下兼容的问题修正。

又比如另外一篇文章内提到：

一、 GNU 风格的版本号命名格式

主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]]

Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]

示例 : 1.2.1, 2.0, 5.0.0 build-13124

二、一些约定

Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。

Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。

Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。

Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。

那么

次版本号与修订号都比较容易理解。令我不解的是，对于手机 App 而言，主版本号的提升一般在什么情况下？ 对于 App 而言，何谓向后兼容性？

我看了下微信 5.0 与 6.0 ，我感觉好像也没多大区别

[loading]

参考 chrome ，现在是刷大版本号的时代。

[chimingphang]

发布日期不好么？

[Hstar]

当需需要一个版本号的时候，丢一个硬币，正面朝上加主版本号，菊花朝上加副版本号，立起来了就改名从 1.0.0 开始。

[skydiver]

http://semver.org/ 语义化版本号，现成的标准

中文版 http://semver.org/lang/zh-CN/

[SharkIng]

看过一个什么二道贩子的文章，大概意思就是楼主说的第一种，例如 1.0.0 这种。

他在文章中分的是主.次.修复，修复主要是指 Bug 的修复，也就是一些小的 Patch ，次是一些功能上的更新. 主的确不好理解，我记得文章中说的意思是以 Milestone 为主，一般来说软件都有一个大纲似的 Milestone ，列出的一般都是主要功能。

所以我的理解就是主要功能的完善，就更新主的，
次要功能，就更新次的