在假设使用依赖管理工具(例如 Maven 2)的情况下，寻找处理项目中主要依赖升级的最佳实践。
具体来说，我感兴趣的是:
- 如何使继承的应用程序保持最新(例如，Spring 1.2.x 到 2.5.x)
- 在这样的大修之后可以采取哪些做法来使应用程序保持在一定程度上是最新的
欢迎提供您自己的经验或您遇到/发现有用的任何文章/论文。
编辑: 更新依赖版本号是微不足道的。我更多的是在寻找你如何根据对依赖项的更改(弃用、删除、参数/返回值类型的更改等)来处理你需要进行的更改。而且，如果将来有缓解这些变化的好方法，那么让您的依赖项保持最新应该可以让您掌握变化并防止浪费大量时间只是为了获得功能“更安全 x 2.1”。
最佳答案
处理依赖项更改的良好做法与应用程序设计的良好做法相同。您希望对您的体系结构进行分层，并尽量减少代码在每个依赖项上的广泛耦合，以便隔离更改，以便升级依赖项不会破坏应用程序的每个部分。接口(interface)编码并保持业务逻辑与基础设施代码分离。
对于次要升级(依赖项的升级点版本)，如果您有一套全面的单元测试来检测由于 API 更改导致的故障，这会有所帮助。这就是为什么它有时有助于编写表面上看起来总是有效的琐碎测试的一个重要原因。这方面的一个例子是编写一个简单的 JDBC 单元测试来执行一个简单的查询。这似乎是一种浪费，直到您在数据库升级后发现 JDBC 驱动程序出现运行时问题(这发生在我身上)。
对于较大的更改(例如在 Spring 等框架的不兼容版本之间升级)，如果您有一些自动化的功能或集成测试，或者至少有一个功能规范，您的 QA 人员可以通过它来验证高级功能，这会有所帮助.如果您要升级的框架 API 差异很大，需要进行广泛的代码更改，则单元测试可能不再相关。
管理从一个依赖版本到另一个不兼容版本的迁移的实际战术部分实际上取决于您在做什么。一个成熟的库将提供某种迁移路径，希望不会要求您重写所有内容。将与框架升级相关的代码更改与与实现新功能相关的更改分开是个好主意。这样，如果出现问题，您就会知道它与框架升级有关，而不是您在实现新功能时出现问题。
之所以如此困难，部分原因是在运行时，您的 JVM 中只能有一个特定依赖项的版本，因此您必须一次更新所有代码。 OSGi 通过允许不同的 OSGi bundle 在同一个环境中运行以依赖不同的依赖版本来解决这个特殊问题，因此您可以在运行时依赖不同的依赖版本。这就是 Eclipse 在不破坏其他插件的情况下管理插件依赖关系的方式。
关于java - 如何处理重大框架/依赖升级？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2405954/