讨论升级方案之前，我们先聊一聊增量升级怎么实现，我暂时认为有两种实现方式：
1.使用大小版本的实现方式
增量包的定义：每次升级，将所有相对于前一个版本更改的文件压缩成一个zip包，即为升级包。 比如当前版本:4.0.0.0。 我们更改了c++的一些功能，只改变了assist.exe.新版本为：4.0.0.1. 那么V4.0.0.1 对比V4.0.0.0的增量就是 assist.exe 一个文件。我们就将assist.exe 压缩到升级包update_4.0.0.1.zip。依次类推每次的更新包。
一个问题：跨了很多版本未升级怎么办？
比如，当前有个客户，在几个月前安装的1.0.0.0，好几个月没有再次登录软件，这时候我们已经进行了几十版的发版，现在版本已经达到了4.0.0.1。怎么办？
当然，我们可以把几十个版本的升级包一个个下载下来，然后一个个升级。但是这样很可能几十个升级包远远大于一个全量包。这时候我们引入大小版本的概念。
大小版本定义：将小幅度升级的版本叫小版本。改变很多的升级，可以叫为大版本（cef、QT版本升级）。
大小版本几个特点:
- 人为设定,上传升级包的时候设定
- 后台（php）认定
- 客户端本身无需关心
- 大版本就是全量包
升级逻辑：我们将本地版本传Localver给后台，后台在Localver与Remotever的中间的所有版本列表中进行搜寻，如果有大版本，则返回距离最新版本Remotever最近的大版本到Remotever之间的所有升级包列表。
例1：
这种情况下，服务器返回的升级包列表是：1.0.0.5与1.0.0.6两个升级包的url.
例2：
这种情况下，服务器返回的升级包列表是：1.0.0.4、1.0.0.5与1.0.0.6三个升级包的url.
客户端的职责有两个：
1. 拿着本地版本询问后台，是否需要升级。
2.如果需要升级，就下载 后台返回的升级包列表 进行升级。
2.使用每个文件一个版本 的实现方式
逻辑：安装包里每个文件，都有一个版本号（MD5\CRC32等）。拿着本地的总版本号去后台请求是否需要升级。后台拿到本地版本号，将其对应的所有文件的版本号与最新的版本号对比。将所有版本有差异的文件列表返回给客户端。客户端只需对文件列表进行下载，然后替换即可。
这种方式如果文件比较多的话，每个文件都会记录一个版本，一个一个对比的话，后台时间可能会久一些。每次下载的文件也会比较多一些，出错的可能性也会比较大了。
现在，我们基于第一种的增量升级方式，描述一下升级流程。
