更新，还是不更新，这是个问题

项目依赖想升不敢升，升了怕有坑，到底怎么整？

依赖 == 第三方库 == Library ≈≈ 某个Github项目

如果东西没坏，就别修理它

升级依赖最糟糕的体验就是，本来没问题，升级升出了问题。

所以如果没有“想升级”之外更充分的理由，尽量别升级依赖。要升级等最少几个月再升级。

从源头上来讲，要尽量减少使用的依赖。

一些对应用架构影响很大的依赖，比如一些MVI框架、复杂的UI嵌套实现等，一定要慎重考虑依赖的必要性，不然未来积重难返。

还有一些专用的、不怎么更新的依赖，要么一个版本用到老，要么拷贝到项目中。

即使是一些作者积极维护、社区反馈热烈、代码质量很高的依赖，也会偶尔出现有坑的版本。更别提那些无人问津、一两个版本就杳无音信的依赖了。在选择前一定要评估评估依赖的维护状态。

针对一些闭源依赖，有新版本时一定要等几个月再尝试。

个人用ben-manes/gradle-versions-plugin来检测需要升级的依赖，和dropbox/dependency-guard来保证升级后的依赖版本（排查出依赖的依赖的升级）。

有新版本时一定要等一两个月再尝试，无论大小。

大部分依赖更新只需修改版本号，这样在发现问题回退版本时很容易。

对于有着Breaking Changes或需要大幅修改项目库的依赖更新，要特别小心。在升级前一定要规划好来避免意外，比如专门开一个Git Branch、进行专门的测试等，以免升级时发现太复杂而放弃，或升级后发现旧版本更适合自己。

虽然一些依赖的大版本更新有着兼容，但也要小心。比如Paging3虽然兼容旧版API，但行为却有些许变化。

因为会进行详尽的测试，这里当然要使用最新稳定版的依赖。

为了项目稳定，尽量不升级依赖，或者只升级那些确定很稳定的依赖。

印象最深刻的要属某次升级了某个开源应用，结果在我的设备上有Bug。作者修了一个月，但这期间等不及只好删掉应用装旧版本，数据全没啦！

教训就是，如果某次更新是无法回退的，且更新失败的代价是难以接受的，那么如果它没坏，就别修理它！