CN104090806B - 升级包、升级请求的处理方法及装置 - Google Patents

Abstract

本发明涉及一种升级包、升级请求的处理方法及装置，其中，软件升级包的处理方法包括：确定当前基线版本，生成所述当前基线版本以及当前基线版本之后的已有版本到最新版本的增量升级包。升级请求的处理方法，包括：接收客户端的升级请求，将客户端软件的版本与当前基线版本进行比较，如果所述客户端软件的版本等于或者高于所述当前基线版本，则向所述客户端发送所述客户端软件的版本到最新版本的增量升级包，如果所述客户端软件的版本低于所述当前基线版本，则向所述客户端发送所述最新版本的全量升级包。通过本发明的技术方案，减少了服务器制作、存储和管理增量升级包的数量，提高了服务器的资源利用率。

Description

升级包、升级请求的处理方法及装置

技术领域

本发明涉及软件升级技术，尤其涉及一种软件升级包和升级请求的处理方法及实现所述方法的装置。

背景技术

随着计算机软件体积的不断增大以及软件版本发布的不断更迭，客户端软件升级成了一个问题。为此人们发明了增量升级方法。增量升级的原理是首先将软件的旧版本的安装包与新版本安装包做差分，生成一个增量升级包(也可以称作补丁包)，例如旧版本的安装包有 5M，新版本的安装包有8M，更新的部分则可能只有3M左右，然后，在升级时只需要下载更新的部分即可，这样可以很大程度上减少流量的损失。用户下载了增量升级包之后，需要在客户端将他们组合起来。一般的做法是先将旧版本软件的安装包，复制到一个临时目录下，将该旧版本软件的安装包与获得的增量升级包进行组合，得到新版本软件的安装包。然后，客户端通过组合后生成的新版本安装包进行升级安装。

增量升级的方法可以节省用户的流量，但是同时也引入了增量升级包的管理问题。在现有技术中，对于增量升级包的管理存在以下两种模式：

1)在服务器端动态制作增量升级包，即服务器端不预先存储，而是根据客户端的升级请求临时制作增量升级包，这种方式对于服务器的性能要求较高，会占用较多服务器的资源，而且如果请求升级的软件较大，生成增量升级包需要耗费很长的时间，会直接影响客户端软件的响应速度。

2)将所有的增量升级包都存放在服务器端，即事先针对所有版本制作升级包，即需要对每个版本的安装包进行差分，生成各个版本到最新版本的增量升级包，并预先存储在服务器中，然后根据客户端的请求，发送对应的增量升级包。对于这种方式，随着版本的迭代，会造成大量的冗余数据，尤其是当版本更新较为频繁时，会给服务器造成巨大的存储和数据管理的负担。

发明内容

本发明实施例的目的在于，提出一种软件升级包和升级请求的处理方法及实现所述方法的装置，以减少服务器端的存储和管理增量升级包的负担。

为了实现上述目的，本发明的实施例提供了一种软件升级包的处理方法，包括：确定当前基线版本；生成所述当前基线版本以及当前基线版本之后的已有版本到最新版本的增量升级包。

本发明实施例还提供了一种升级请求的处理方法，包括：接收客户端的升级请求；将客户端软件的版本与当前基线版本进行比较，如果所述客户端软件的版本等于或者高于所述当前基线版本，则向所述客户端发送所述客户端软件的版本到最新版本的增量升级包，如果所述客户端软件的版本低于所述当前基线版本，则向所述客户端发送所述最新版本的全量升级包。

本发明实施例还提供了一种软件升级包的处理装置，包括：基线版本确定模块，用于确定当前基线版本；增量升级包生成模块，生成所述当前基线版以及当前基线版本之后的已有版本到最新版本的增量升级包。

本发明实施例还提供了一种升级请求的处理装置，包括：升级请求接收模块，用于接收到客户端的升级请求；升级包发送模块，用于将客户端的软件的版本与当前基线版本进行比较，如果所述客户端的软件的版本等于或者高于所述当前基线版本，则向所述客户端发送所述客户端的软件的版本到最新版本的增量升级包；如果所述客户端的软件的版本低于所述当前基线版本，则向所述客户端发送最新版本的全量升级包。

本发明实施例的软件升级包和升级请求的处理方法及实现所述方法的装置，能够清除当前基线版本以后的版本到最新版本的增量升级包以外的增量升级包，有效地节约了服务器的存储空间，减少了服务器存储和管理增量升级包的负担。

附图说明

图1为本发明实施例一的软件升级包的处理方法的流程图。

图2为本发明实施例二的软件升级包的处理方法的流程图。

图3为本发明实施例三的确定当前基线版本的流程图之一。

图4为本发明实施例三的确定当前基线版本的流程图之二。

图5为本发明实施例四的确定当前基线版本的流程图。

图6为本发明实施例五的升级请求的处理方法的流程图。

图7为本发明实施例六的软件升级包的处理装置的结构示意图之一。

图8为本发明实施例六的软件升级包的处理装置的结构示意图之二。

图9为本发明实施例七的升级请求的处理装置的结构示意图。

具体实施方式

本发明的实施例提出了一种基于基线版本的思想对软件的增量升级包以及对于客户端的升级请求进行处理的方法。需要说明的是，在本发明的实施例中，“以后”、“以前”的表述的范围包含中心词，“之前”、“之后”的表述的范围不包含中心词，软件升级包包括了增量升级包和全量升级包，已有版本是相对于最新版本而言的概念，其包含已有基线版本、已有基线版本之前的版本以及除了最新版本之外的已有基线版本之后的版本。

下面将结合附图对本发明实施例进行详细描述。

实施例一

如图1所示，其为本发明实施例一的软件升级包的处理方法的流程图之一，其包括：

步骤11：确定当前基线版本。

步骤12：生成当前基线版本以及当前基线版本之后的已有版本到最新版本的增量升级包。在实际应用中，该处理流程还存在一种特殊情况，即如果当前基线版本为最新版本，则将不会执行步骤12。在本发明的实施例中，首先确定一个当前基线版本，在此基础上，以该当前基线版本为界，对该当前基线版本以后的版本制作增量升级包，而对于当前基线版本之前的版本将不再制作到最新版本的增量升级包。通过这种处理方法，减少了服务器制作、存储和管理增量升级包的数量，提高了服务器的资源利用率。对于当前基线版本的确定，可以根据软件的不同、网络环境、服务器配置等实际因素，采用不同的确定当前基线版本的方案。

进一步地，步骤11中，确定当前基线版本可以采用如下几种方式：

方式一：将最新版本的安装包与已有版本的安装包进行差分，根据差分获得的差分量确定当前基线版本。例如，现在已经存在了多个已有版本，而之前并未执行过确定当前基线版本的操作，在这种情况下，可以将最新版本的安装包与全部的已有版本的安装包进行差分，根据差分量从已有版本中选择适当的版本作为当前基线版本。

差分量直接体现了已有版本的安装包与最新版本的安装包之间的数据量的差距，而制作增量升级包的意义就是要减少数据传输量，如果数据量的差距过大，则就没有必要制作增量升级包，而直接采用全量升级包的方式即可。因此，以差分量为依据进行判断，能够客观地评估出相对于最新版本的升级包而言，哪个版本更适合作为基线版本，以达到合理地制作和管理增量升级包的目的。

进一步地如果在软件发布最初版本时就开始使用本发明实施例的处理方法，即已经存在已有基线版本的情况下，则进行差分的操作可以具体为将最新版本与作为已有基线版本的已有版本以及已有基线版本之后的已有版本进行逐一差分，即差分操作只针对已有基线版本之后的版本进行，并且可以按照从先到后的顺序逐一进行。对于该差分的操作，可以实际生成一个差分包，然后获取该差分包的大小作为差分量，也可以不实际生成差分包，而直接通过计算获得差分量。在实际的应用中，可以采用现有的BSDiff算法，BSDiff是一个二进制包的差异包比较和生成算法，能够生成两个安装包之间的差分包，当然也可以采用其他类似算法等，只要能计算出最新版本的安装包与已有基线版的安装包之间的差分包或者差分量即可。

其中，对于根据差分获得的差分量确定当前基线版本可以具体采用如下几种方式：

方式11：计算差分量与已有版本的安装包的大小的比值，根据该比值确定当前基线版本。具体地，如果差分量与已有版本的安装包的大小的比值大于预定的第一阈值，则判断为该已有版本不适合作为当前基线版本；如果差分量与已有版本的安装包的大小的比值小于或等于预定的第一阈值，则判断为该已有版本适合作为当前基线版本。方式11是间接地以差分量作为判断标准，即以差分运算获得的差分量与已有基线版本的安装包的大小的比值作为判断标准。举例来说，假设存在版本A、版本B和版本C，版本B为已有的基线版本，现在将发布一个最新版本D，则首先通过BSDiff算法，生成一个版本B到版本D的差分包P1,如果sizeof(P1)/sizeof(B)<＝Delta,则保持已有的基线版本不变，即将版本B继续作为当前基线版本，如果sizeof(P1)/sizeof(B)> Delta，则将重新确定当前基线版本。其中，sizeof表示获取数据包的大小的函数，Delta表示预先设定的第一阈值，第一阈值可以根据实际需要灵活设定，例如，可以设置为0.8。

采用该方式11的意义在于，如果差分量与已有基线版本的安装包的大小相比，其占的比重过大，说明基于该已有基线版本制作的增量升级包相对于该已有基线版本的安装包差异较大，从效率而言，不如直接采用全量升级的方式。

方式12：计算差分量与最新版本的安装包的大小的比值，根据该比值确定当前基线版本。具体地，如果差分量与最新版本的安装包的大小的比值大于预定的第二阈值，则判断为该已有版本不适合作为当前基线版本；如果差分量与最新版本的安装包的大小的比值小于或等于预定的第二阈值，则判断为该已有版本适合作为当前基线版本。该方式12也是间接地以差分量作为判断标准，与方式1不同之处在于，是以差分运算获得的差分量与最新版本的安装包的大小的比值作为判断标准。采用该方式12的意义在于，如果差分量与最新版本的安装包的大小相比，其占的比重过大，说明增量升级包本身已经和最新版本的全量升级包已经较为接近了，从效率而言，不如直接采用全量升级的方式。第二阈值可以根据实际需要灵活设定，例如，也可以设置为 0.8。

方式13：直接根据差分量来确定当前基线版本。具体地，如果差分量大于预定的第三阈值，则判断为该已有版本不适合作为当前基线版本；如果差分量小于或等于预定的第三阈值，则判断为该已有版本适合作为当前基线版本。该方式13是直接以差分量作为判断标准的，该方式的优点在于，不需要再进行额外的运算，判断操作较为简便。

需要指出的是，在上述的判断过程中，以差分量或者差分量的比值是否小于或等于各个阈值作为肯定的判断标准，而将大于各个阈值作为否定的判断标准，本领域技术人员应该能够理解，也可以以差分量或者差分量的比值是否小于各个阈值作为肯定的判断标准，而将大于或等于各个阈值作为否定的判断标准，这两种方式是等同的。

通过上述的方式11-13对软件的版本进行判断，能够较为合理地确定出当前基线版本，然后再以当前基线版本为界限，生成有限个新的增量升级包，并淘汰冗余的增量升级包，从而能够减少服务器的制作、存储和管理升级包的负担。

方式二：通过对多个客户端所使用的软件的版本进行统计分析，将使用最多的已有版本设定为当前基线版本。在该方式中，通过将用户使用最多的版本作为当前基准版本，能够在保证大多数用户采用增量升级，而对于少数用户使用的当前基准版本之前的版本，服务器将不再生成和存储到最新版本的增量升级包，从而能够提高服务器的使用效率。

方式三：作为一种灵活的方式，还可以通过人为指定的方式确定基线版本。即接收输入的基线版本指定消息，将该基线版本指定消息所指定的版本作为当前基线版本。在该方式中，可以通过人为指定的方式设定当前基线版本，从而可以根据需要灵活指定。例如，许多软件版本的开发存在多个系列版本，如版本1.0、版本1.01、版本1.02、版本2.0、版本2.01等，一般来说版本1.0和版本2.0这种整数版本的改动较大，因此，可以通过人为输入的方式将该整数版本指定为当前基线版本，在没有下一个整数版本更新之前，保持该设定。

实施例二

如图2所示，在实施例一的基础上，本实施例的软件升级包的处理方法还可以包括：步骤13：根据基线版本清理增量升级包。需要说明的是，步骤13不一定要在步骤12之后执行，也可以在步骤11之后执行或者与步骤12同时执行。

进一步地，步骤13可以采用如下方式：只删除早期版本对应的增量升级包。举例来说，存在版本A、版本B、版本C，然后发布了最新版本D，之前已经存在增量升级包AC、增量升级包BC,如果将当前基线版本确定为版本B，则将生成增量升级包BD、增量升级包CD，同时将删除增量升级包AC。通过该处理，清空了服务器中存储的作为冗余数据的早于当前基线版本的早期版本对应的增量升级包，从而提高了服务器的存储和管理效率。

此外步骤13也可以采用如下方式：删除当前基线版本之后的已有版本到最新版本的增量升级包之外的已有版本的增量升级包。该处理除了删除早期版本对应的增量升级包外，还删除了除了最新版本以外的各个版本之间的升级包，举例来说，存在版本A、版本B、版本C，然后发布了最新版本D，之前已经存在增量升级包AC、增量升级包BC, 在将当前基线版本确定为版本B后，生成增量升级包BD、增量升级包 CD，同时删除增量升级包AC、增量升级包BC。即将除了新生成的增量升级包之外，删除了之前的全部升级包，这样能够进一步提高了服务器的存储和管理效率。

实施例三

本实施例将对软件升级包的处理方法具体流程进行进一步详细说明。本发明的实施例的处理方法，至少可以应用于如下两种情形：

情形一：在软件发布最初版本时就开始使用本发明实施例的处理方法，即当只有一个最初版本时，将该最初版本作为当前基线版本即可，以后每次发布新版本再重新进行一次当前基线版本的确定操作，从而根据确定结果，来更新或保持当前基线版本。

情形二：在起初没有使用本发明实施例的处理方法(最初没有采用基于当前基线版本来管理软件升级包)，而是当已经发布了许多版本之后才开始使用本实施例的处理方法。例如，当前已经存在了多个软件版本，则可以在再发布新版本时，开始执行本发明实施例的方法，同样可以减少服务器制作、存储和管理增量升级包的负担。

此外，需要说明的是，在上述的步骤11中，在执行确定当前基线版本的操作后，如果将最新版本确定为当前基线版本(例如，当前基线版本之前的版本不适合作为当前基线版本，或者刚发布了软件的第一个版本等情况)，在这种情况下，将不存在生成增量升级包的操作，则直接结束处理操作。

本实施例将针对上述的情形一进行详细说明，即在软件发布最初版本时就开始使用本发明的软件升级包的处理方法，如图3所示，其为本发明实施例三的确定当前基线版本的流程图之一，确定当前基线版本的操作(即实施例一的步骤11)可以具体为：

步骤101：将最新版本的安装包与已有基线版的安装包进行差分。

步骤102：将该已有基线版本作为被判断版本，根据差分获得的差分量判断该被判断版本是否适合作为当前基线版本，如果适合，则执行步骤103，如果不适合，则执行步骤104。

步骤103：将被判断版本作为当前基线版本，即继续采用该已有基线版本作为当前基线版本。

步骤104：从已有基线版本之后的版本中选择一个版本作为当前基线版本，然后结束。

进一步地，上述的从已有基线版本之后的版本中选择一个版本作为当前基线版本可以进一步包括：如果已有基线版本与最新版本之间存在中间版本，则遍历中间版本进行如下处理：将最新版本的安装包与当前遍历的中间版本的安装包进行差分，将该当前遍历的中间版本作为被判断版本，根据差分获得的差分量判断该被判断版本是否适合作为当前基线版本，如果适合，则将该被判断版本作为当前基线版本 (即将当前遍历的中间版本作为当前基线版本)并停止遍历，如果不适合并且还存在未遍历的中间版本，则继续进行遍历，如果不适合并且不存在未遍历的中间版本，则将最新版本作为当前基线版本。如果已有基线版本与最新版本之间不存在中间版本，则将最新版本作为当前基线版本。

上述的处理可以表示为图4所示的流程，如图4所示，其为本发明实施例三的确定当前基线版本的流程图之二，从已有基线版本之后的版本中选择一个版本作为当前基线版本(即上述的步骤104)可以具体包括：

步骤1041：判断已有基线版本与最新版本之间是否存在中间版本，如果存在，则执行步骤1042，如果不存在，则执行步骤1048。

步骤1042：选择一个中间版本作为当前遍历的中间版本。

步骤1043：将最新版本的安装包与当前遍历的中间版本的安装包本进行差分。

步骤1044：将该当前遍历的中间版本作为被判断版本，根据差分获得的差分量判断该被判断版本是否适合作为当前基线版本，如果适合，则执行步骤1045，如果不适合，则执行步骤1046。

步骤1045：将该被判断版本作为当前基线版本(即将当前遍历的中间版本作为当前基线版本)，然后结束本流程。

步骤1046：判断是否存在未遍历的中间版本，如果存在，则执行步骤1047，如果不存在，则执行步骤1048。

步骤1047：选择下一个中间版本作为当前遍历的中间版本，并执行步骤1043。

步骤1048：将最新版本作为当前基线版，然后结束本流程。

在上述操作中，通过遍历已有基线版本与最新版本之间存在的中间版本，以最新版本的安装包与当前遍历的中间版之间的差分量作为判断标准，来寻找出适合作为当前基线版本的中间版本，这样，能够合理地确定出较为适合的当前基线版本。

此外，上述的遍历中间版本可以按照由旧到新的顺序遍历中间版本，也可以按照由新到旧的顺序遍历中间版本。当然，也可以采用其他顺序遍历中间版本，例如，随机的方式等等。具体的遍历方式，可以根据软件版本之间的变化规律来灵活设置。

对于本实施例中，根据差分获得的差分量判断该被判断版本是否适合作为当前基线版本可以采用上面提及的方式11-13，相关的作用和效果与前述相同，在此不再赘述。

实施例四

本实施例将针对上述的情形二进行详细说明，即在起初没有使用本发明实施例的处理方法(最初没有采用基于当前基线版本来管理软件升级包)，而是当已经发布了许多版本之后才开始使用本实施例的处理方法。在该情形下，确定当前基线版本可以采用如下方式：遍历已有版本进行如下处理：将最新版本的安装包与当前遍历的已有版本的安装包进行差分，将该当前遍历的已有版本作为被判断版本，根据差分获得的差分量判断该被判断版本是否适合作为当前基线版本，如果适合，则将该被判断版本作为当前基线版本并停止遍历，如果不适合并且还存在未遍历的已有版本，则继续进行遍历，如果不适合且不存在未遍历的已有版本，则将最新版本作为当前基线版本。

针对情形二的处理方法，可以表示为图5的处理流程，如图5所示，其为本发明实施例四的确定当前基线版本的流程图，确定当前基线版本包括：

步骤101’：选择一个已有版本作为当前遍历的已有版本。

步骤102’：将最新版本的安装包与当前遍历的已有版本的安装包进行差分。

步骤103’：将该当前遍历的已有版本作为被判断版本，根据差分获得的差分量判断该被判断版本是否适合作为当前基线版本，如果适合，则执行步骤104’，如果不适合，则执行步骤105’。

步骤104’：将被判断版本作为当前基线版本(即将当前遍历的已有版本作为当前基线版本)，然后结束本流程。

步骤105’：判断是否存在未遍历的已有版本，如果存在，则执行步骤106’，如果不存在，则执行步骤107’。

步骤106’：选择下一个已有作为当前遍历的已有版本，并执行步骤102’。

步骤107’：将最新版本作为当前基线版本，然后结束本流程。

本实施例适用于在起初没有使用本发明实施例的处理方法，而是当已经发布了许多版本之后才开始使用的情形，通过本实施例的处理方法，对已经存在的各个软件的版本进行了重新整理，确定了当前基线版本，之后便可以采用实施例二的技术方案进行处理了，从而也实现了减少服务器制作、存储和管理增量升级包的数量，提高服务器的资源利用率的技术效果。

对于本实施例中，根据差分获得的差分量判断该被判断版本是否适合作为当前基线版本可以采用上面提及的方式11-13，相关的作用和效果与前述相同，在此不再赘述。

实施例五

基于上述实施例一至四所描述的软件升级包的处理方法，本实施例还提出了一种升级请求的处理方法，如图6所示，其为本发明实施例四的升级请求的处理方法的流程图，其包括：

步骤21：接收客户端的升级请求。

步骤22：将客户端软件的版本与当前基线版本的进行比较，如果客户端软件的版本等于或者高于当前基线版本，则执行步骤23，如果客户端软件的版本低于当前基线版本，则执行步骤24；其中，客户端软件的版本的相关信息一般会包含在升级请求中，当然也可以通过其他方式发送给服务器或者预先存储在服务器中。

步骤23：向客户端发送客户端软件的版本到最新版本的增量升级包。

步骤24：向客户端发送最新版本的全量升级包。

对客户端来说，如果接收到全量升级包，则直接将该全量升级包作为安装软件直接安装，如果接收到增量升级包，则可以将之前存储的旧版本的安装包与该增量升级包进行组合生成全量升级包进行安装，例如，可以使用BSpatch算法进行处理，BSpatch算法是与BSdiff算法相对应的一种将二进制包进行组合的算法，通过BSpatch算法能够将旧版本的安装包与增量升级包进行组合，生成完整的新版本安装包，然后客户端直接运行该新版本的安装包完成安装。

本实施例的升级请求的处理方法，不再像现有技术的升级方式那样，无差别地对客户端进行升级，而是将客户端软件的版本与当前基线版本的进行比较，根据比较结果选择全量升级还是增量升级，从而方便了服务器对于增量升级包的管理，减少了服务器制作、存储和管理增量升级包的负担。

实施例六

如图7所示，其为本发明实施例六的软件升级包的处理装置的结构示意图，包括：基线版本确定模块1，用于确定当前基线版本；增量升级包生成模块2，用于生成当前基线版本以及当前基线版本之后的已有版本到最新版本的增量升级包。

本实施例的软件升级包的处理装置可以设置于服务器端，通过本实施例的软件升级包的处理装置，在确定了当前基线版本后，能够减少增量升级包的制作储量，从而减少了服务器制作、存储和管理增量升级包的数量，提高了服务器的资源利用率。

与上述实施例一的处理方法相对应地，在本实施例中，基线版本确定模块1所执行的确定当前基线版本操作可以采用如实施例一中所说明的方式一至方式三，在此不再赘述。对于确定当前基线版本的具体执行过程可以采用如实施例三和实施例四所描述的过程。在此不再赘述。

此外，如图8所示，本实施例的处理装置，还可以包括：增量升级包清理模块3，用于根据当前基线版本清理增量升级包。对于具体的清理增量升级包的方式可以采用实施例二所描述的方式。

实施例七

如图9所示，其为本发明实施例七的升级请求的处理装置的结构示意图，其包括：升级请求接收模块4，用于接收到客户端的升级请求；升级包发送模块5，用于将客户端软件的版本与当前基线版本进行比较，如果客户端软件的版本等于或者高于当前基线版本，则向客户端发送客户端软件的版本到最新版本的增量升级包；如果客户端软件的版本低于当前基线版本，则向客户端发送最新版本的全量升级包。

通过本实施例的升级请求的处理装置，将客户端软件的版本与当前基线版本的进行比较，根据比较结果选择全量升级还是增量升级，从而方便了服务器对于增量升级包的管理，减少了服务器制作、存储和管理增量升级包的负担。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种软件升级包的处理方法，其特征在于，包括：

将最新版本的安装包与作为已有基线版本的已有版本以及已有基线版本之后的已有版本进行逐一差分，根据差分获得的差分量与预定的阈值的比较结果确定当前基线版本，其中，基线版本用于作为是否制作增量升级包的界限版本；

生成所述当前基线版本到最新版本的增量升级包，以及生成当前基线版本之后的已有版本到最新版本的增量升级包。

2.根据权利要求1所述的处理方法，其特征在于，所述将最新版本的安装包与作为已有基线版本的已有版本以及已有基线版本之后的已有版本进行逐一差分，根据差分获得的差分量与预定的阈值的比较结果确定当前基线版本包括：

计算所述差分量与所述已有基线版本的安装包的大小的比值，根据该比值与预定的第一阈值的比较结果确定当前基线版本；

或者，

计算所述差分量与所述最新版本的安装包的大小的比值，根据该比值与预定的第二阈值的比较结果确定当前基线版本。

3.根据权利要求1所述的处理方法，其特征在于，还包括：根据所述当前基线版本清理增量升级包。

4.根据权利要求3所述的处理方法，其特征在于，所述根据当前基线版本清理增量升级包包括：删除所述当前基线版本之前的已有版本的增量升级包。

5.根据权利要求4所述的处理方法，其特征在于，所述根据所述当前基线版本清理增量升级包还包括：删除所述当前基线版本之后的已有版本到最新版本的增量升级包之外的已有版本的增量升级包。

6.一种升级请求的处理方法，其特征在于，包括：

接收客户端的升级请求；

将客户端软件的版本与当前基线版本进行比较，如果所述客户端软件的版本等于或者高于所述当前基线版本，则向所述客户端发送所述客户端软件的版本到最新版本的增量升级包，如果所述客户端软件的版本低于所述当前基线版本，则向所述客户端发送所述最新版本的全量升级包；

其中，基线版本用于作为是否制作增量升级包的界限版本。

7.一种软件升级包的处理装置，其特征在于，包括：

基线版本确定模块，用于将最新版本的安装包与作为已有基线版本的已有版本以及已有基线版本之后的已有版本进行逐一差分，根据差分获得的差分量与预定的阈值的比较结果确定当前基线版本，其中，基线版本用于作为是否制作增量升级包的界限版本；

增量升级包生成模块，用于生成所述当前基线版本到最新版本的增量升级包，以及生成当前基线版本之后的已有版本到最新版本的增量升级包。

8.根据权利要求7所述的处理装置，其特征在于，所述将最新版本的安装包与作为已有基线版本的已有版本以及已有基线版本之后的已有版本进行逐一差分，根据差分获得的差分量与预定的阈值的比较结果确定当前基线版本包括：

计算所述差分量与所述已有基线版本的安装包的大小的比值，根据该比值与预定的第一阈值的比较结果确定当前基线版本；

或者，

计算所述差分量与所述最新版本的安装包的大小的比值，根据该比值与预定的第二阈值的比较结果确定当前基线版本。

9.根据权利要求7所述的处理装置，其特征在于，还包括：

增量升级包清理模块，根据所述当前基线版本清理增量升级包。

10.根据权利要求9所述的处理装置，其特征在于，所述根据当前基线版本清理增量升级包包括：删除所述当前基线版本之前的已有版本的增量升级包。

11.根据权利要求10所述的处理装置，其特征在于，所述根据当前基线版本清理增量升级包还包括：删除所述当前基线版本之后的已有版本到最新版本的增量升级包之外的已有版本的增量升级包。

12.一种升级请求的处理装置，其特征在于，包括：

升级请求接收模块，用于接收到客户端的升级请求；

升级包发送模块，用于将客户端的软件的版本与当前基线版本进行比较，如果所述客户端的软件的版本等于或者高于所述当前基线版本，则向所述客户端发送所述客户端的软件的版本到最新版本的增量升级包；如果所述客户端的软件的版本低于所述当前基线版本，则向所述客户端发送最新版本的全量升级包；

其中，基线版本用于作为是否制作增量升级包的界限版本。