第三方库的更新和升级
操作方法
- 01
模块化、代码重用等思维的引领下，各种不同功能的库不断出现，基本涵盖了所有功能需求，极大加速了软件开发效率。 另一方面，包管理工具的流行简化了引用过程。不再需要下载库文件，添加到项目目录。 第三方库也是一种产品，一样存在生命周期，这样就会有升级的问题产生。 为什么要升级 第三方库也是人创造的，同样会有效率，代码质量等问题。伴随着升级会有各种修复、优化和新的特性。 及时的升级可以排除潜在的bug，提升效率，如果有需要还可以根据API的升级简化代码并优化流程。 对于一个成熟的、经过广泛验证的第三方库，比如Spring、Hibernate等等。它们的方方面面经过时间的考研，在一个稳定的版本范围内都是可信的。所谓的版本范围是指标准版本号。 如果第三方依赖库的管理是手动的，那么升级的步骤就很无趣了。你需要定期访问你所使用的库的主页，检查是否有升级，然后手动下载新版本，覆盖旧版本。 如果使用包管理工具或者构建工具，如npm、gradle等，那么升级就比较简单了，直接修改配置本身然后执行更新命令就可以完成了。 Gradle中的版本管理 npm很方便，使用也简单，所以下面的例子都是以gradle为例的。 在gradle中如果你需要引入一个第三方包，你只需要在配置中写道： 1 2 3 4 5 6 7 8 9 10 apply plugin:'java'repositories { mavenCentral() } dependencies { compilegroup:'org.hibernate', name:'hibernate-core', version:'3.6.7.Final'testCompilegroup:'junit', name:'junit', version:'4.11'} 这样gradle就可以自动下载相关的库，而当你需要升级的时候你只需要修改version配置即可。当然更多的人可能习惯偏好更紧凑的写法： 1 2 3 4 dependencies{ compile'org.hibernate:hibernate-core:3.6.7.Final'testCompile'junit:junit:4.11'} 不过以上的修改都需要你在一大篇缩进不同的字符串中来回寻找，特别是以下情况的时候你可以就觉得有点不方便了： 1 2 3 4 testCompile( "org.hamcrest:hamcrest-core:1.3", "org.hamcrest:hamcrest-library:1.3" ) 最简单也是最具可读性的方法是把版本号抽取出来作为项目的配置： 1 2 3 4 5 6 7 8 project.ext { hamcrestVersion ='1.3'} testCompile("org.hamcrest:hamcrest-core:$hamcrestVersion","org.hamcrest:hamcrest-library:$hamcrestVersion") 这样所有的升级只需要修改hamcrestVersion了。当然有时候你需要一个更宽松且智能的版本号，比如2.5.+。你需要的是主版本号为2,副版本号为5的最新的第三方依赖库。如果这个库是严格遵循版本规范的，那么你就可以享受不断修复的稳定版本了。# 如果了解最新的版本带‘+’号的版本号可以享受到便利性，但是它也是有局限和风险的。比如’2.5.+’比’2.+’更谨慎。还有一种极端的情况，比如你使用的是’0.2.+’，结果新版本已经是’0.6.+’。其实这种情况也不是多么罕见…至少我前些日子才发现我一直使用async依赖就是这样的。当然可以通过访问官方网站来了解当前的版本号，但是这样未必太麻烦了，我一般采用两种方法来操作。一是使用依赖版本跟踪服务，比如david-dm，它可以监控你的nodejs依赖。