方式】。
【附图说明】
[0059]通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中:
[0060]图1示出了根据本发明一个实施例的一种文件的升级发布方法的流程图；
[0061]图2示出了根据本发明又一个实施例的一种文件的升级发布方法的流程图；
[0062]图3示出了根据本发明一个实施例的一种文件的升级发布装置的结构图；
[0063]图4示出了根据本发明又一个实施例的一种文件的升级发布装置的结构图。
【具体实施方式】
[0064]下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
[0065]图1示出了根据本发明一个实施例的一种文件的升级发布方法的流程图。如图1所示，该方法包括:
[0066]步骤S110，导入指定文件的当前发布版本的发布包。
[0067]本步骤中，将当前要发布的版本的发布包导入到发布平台中。
[0068]步骤S120，如果当前发布版本为该指定文件的初始版本，将该发布包进行全量发布。
[0069]由于初始版本时第一个版本，因此只能全量发布。
[0070]步骤S130，如果当前发布版本为该指定文件的升级版本，根据预设策略确定需要当前发布版本与之生成增量的该指定文件的一个或多个已发布版本。
[0071]本步骤中，只需要根据预设策略确定少数的已发布版本。
[0072]步骤S140，生成当前发布版本的发布包与所确定的一个或多个已发布版本的发布包之间的增量文件，并根据当前以及之前生成的增量文件生成包含增量升级路径的增量升级列表。
[0073]增量文件:记录新版本相对于旧版本所发生的变化的文件。一般来说，版本号之间跨度越大，版本间变化的内容的越多，增量文件越大，反之越小。
[0074]本步骤中，生成当前发布版本和所确定的少数几个已发布版本之间增量文件，而不需要生成当前发布版本和所有之前的已发布版本之间的增量文件，避免了大量的数据冗余，大大减少的升级所需的资源，如存储增量文件所需的存储资源、生成增量文件所需的资源等等。
[0075]步骤S150，发布所生成的增量文件，将所生成的增量升级列表下发到供客户端进行增量升级的配置文件中。
[0076]这样，当客户端想要对本地的该指定文件进行升级时，先到配置文件查询从本地的版本升级的更高版本时的路径，获得该路径对应的增量文件信息，然后去下载相应的增量文件进行升级。
[0077]图1所示的方法，解决了全部版本以全量发布时的流量耗费问题，并且每次增量发布时选择性地生成当前发布版本的发布包与一个或多个已发布版本的发布包之间的增量文件，而不是生成当前发布版本的发布包与所有已发布版本的发布包之间的增量文件，进一步减少了文件升级所需的资源。
[0078]需要说明的是，这里所述的文件可以是应用软件，也可以是各类数据库。
[0079]在本发明的一个实施例中，图1所示的方法中，如果当前发布版本为该指定文件的升级版本，在根据预设策略确定需要当前发布版本与之生成增量的该指定文件的一个或多个已发布版本之前，该方法进一步包括:判断是否需要使用全量发布，是则将该发布包进行全量发布。这是因为，在有些情况下即使是升级版本，也需要进行全量发布，具体判断是否需要使用全量发布包括如下中的一种或多种情况:
[0080]al)如果当前发布版本的发布包是已下线版本的重新导入包，则确定需要使用全量发布。这种情况是指当前发布版本并不是最新版本，而是之前已发布但又下线版本在进行漏洞修复后的重新导入包。此时只能全量发布。因为之前已经生成了增量文件，先后两个版本的差异会导致增量文件不一样，会导致该版本之后的版本都会出现文件，所以必须全量发布。
[0081]a2)如果该指定文件未开启增量升级发布，则确定需要使用全量发布。发布平台会提供“增量控制”选择项，只有选择了该项的文件才进行增量发布，如果没有选择则进行全量发布。这可以让用户自主选择是否进行增量发布。
[0082]a3)如果当前发布版本所支持的操作系统位数与之前已发布版本所支持的操作系统位数不同，则确定使用全量发布。一般会操作系统会有32位和64位，如Windows系统。如果发一个版本只能支持32位，那么只能和之前已发布的支持32位的版本生成增量文件。
[0083]在本发明的一个实施例中，图1所示方法中所述增量升级列表包括:从不同的已发布版本升级到当前发布版本的增量升级路径。其中，每条增量升级路径包括:从对应的已发布的版本升级到当前发布版本所需经过的版本，以及对应所需的增量文件信息。增量文件信息包括:增量文件的下载地址，或者从指定地址下载增量文件的MD5值。
[0084]例如，一条增量升级路径是从版本4升级到版本16的路径，其具体为4-5-15-16，即从版本4升级到版本5，从版本5升级到版本15，再从版本15升级到版本16。所需的增量文件为:版本5与版本4之间的增量文件，版本15与版本5之间的增量文件，以及版本16与版本15之间的增量文件。增量文件的下载地址及下载URL。或者，已经知道从指定地址下载，此时MD5值作为增量文件的唯一标识可以识别是哪个增量文件。
[0085]在本发明的一个实施例中，图1所示的方法中，如果当前发布版本为该指定文件的升级版本，则在生成包含增量升级路径的增量升级列表之后，并在将所生成的增量升级列表下发到供客户端进行增量升级的配置文件中之前，该方法进一步包括如下中的一项或多项:
[0086]bl)如果生成的一个增量文件的大小，大于第一预设阈值，则从增量升级列表中删除包含该增量文件的增量升级路径。例如，第一预设阈值可以设置为1M，如果生成的增量文件大于1M，则放弃对应的增量路径。
[0087]b2)如果生成的一个增量文件的大小与当前发布版本的发布包的大小的比值，大于第二预设阈值，则从增量升级列表中删除包含该增量文件的增量升级路径。例如，第二预设阈值可以设置50%，如果新版本全量发布时8M，则增量文件不能超过4M。
[0088]b3)如果一条增量升级路径上增量文件的大小总和，大于当前发布版本的发布包的大小，则从增量升级列表中删除该增量升级路径。即如果增量升级所需要下载的增量文件大小已经大于新版本发布包的大小的话，增量升级已经没有意义了。
[0089]上述几种增量升级路径过滤方法都是为了避免增量升级反而比全量升级还要费流量的情况。
[0090]在本发明的一个实施例中，图1所示的方法进一步包括:提供参数设置接口，通过该参数设置接口接收输入的第一预设值和/或第二预设值。即增量发布平台的用户可以自主选择和设置第一预设值和第二预设值。
[0091]在本发明的一个实施例中，图1所示的方法，在生成当前发布版本的发布包与所述一个或多个已发布版本的发布包之间的增量文件时，该方法进一步包括:如果用户自定义勾选了一个或多个已发布版本，则还生成当前发布版本的发布包与用户自定义勾选的一个或多个已发布版本的发布包之间的增量文件。这可以让用户自主定义想生成增量文件的版本。
[0092]现实情况中，有一些如下情况的特殊需求:某文件有两个分支，一些版本只发布beta版(1001、1003、1005等)，一些版本只发布正式版(1002、1004、1006)，且版本号穿插着，两个分支的文件差异较大，不能够按照默认设置1002-1001、1003-1002的形式生成增量，所以提供了自定义勾选增量生成的功能。自定义勾选增量的意义:可以自定义任意低版本到目标版本直接生成diff，首先它解决了更复杂版本之间升级，其次解决了增量跳数限制的问题，也能实际满足生产情况下的需求。
[0093]在本发明的一个实施例中，图1所示的方法，在将该发布包进行全量发布之前，或者在发布所生成的增量文件之前，该方法进一步包括:对待发布内容进行测试验证，如果测试验证通过则进行发布，否则进行修正后重新导入。这里的测试验证时发布前的测试验证，如果不通过则需要修改后重新导入再发布。
[0094]在本发明的一个实施例中，图1所示方法中所述根据预设策略确定需要当前发布版本与之生成增量的该指定文件的一个或多个已发布版本包括:预设一个或多个增量跳数；如果当前发布版本的编号能够被一个增量跳数整除，则找到版本编号比放前发布版本的编号低该增量跳数的已发布版本。
[0095]为了方便记录各版本的先后序号，在本发明的实施例中，将指定文件的各级版本按照先后顺序从O开始进行整数编号。这样就不受指定文件的发布实际版本号是否连续的影像了。例如，发布初始版本时赋予编号O，之后，每发布一个新版本在上一版本编号上加I即为该新版本的编号，这里新赋予的编号成为内部编号。举例说明如下(增量跳数为1、5、10 和 20):
[0096]A)导入版本时，发布平台会为使用增量的版本进行内部编号，初始全量版本编号为0，之后版本编号依次加1，如
[0097]1.0.0.1000->0，
[0098]1.0.0.1001_>1，
[0099]1.0.0.1002_&