假设使用依赖关系管理工具（例如，Maven 2），寻找在项目中处理主要依赖项升级的一些最佳实践。
具体来说，我对以下内容感兴趣：
欢迎您自己的经历或任何您认为有用的文章/论文。
修改 更新依赖项版本号非常简单。基于对依赖项的更改（弃用，删除，对参数/返回值中的类型的更改等等），我更关注如何处理您需要进行的更改。如果有一种很好的方法可以在将来缓解这些变化，那么保持您的依赖关系是最新的应该让您能够随时掌握变化并防止浪费大量时间获得功能'更安全x 2.1'。
答案 0 :(得分：1)
根据我的经验，依赖项升级是由依赖项所拥有的所需功能实现的，可以修复依赖项中直接影响您自己的代码，支持新Java版本或保持代码兼容的错误。特定标准（关于影响安全性的依赖关系）。如果您的代码不属于这些必要的区域之一，我不会费心保持它们是最新的，而是只在必要时更新它们，因为从发行版到发行版的更新实际上可能会在您的应用程序中引入错误。
我总是发现最佳实践始于在应用程序上完成生产周期，将其作为稳定版本发布，并在下一个开发迭代中手动更新依赖项。在父POM中集中您的版本将导致最小的依赖版本修改和增加的可扩展性。假设你正在使用Maven：
<dependency>
<groupId>your.dep.group</groupId>
<artifactId>your-artifact-id</artifactId>
<version>${desiredVersion}</version>
</dependency>
答案 1 :(得分：1)
处理依赖项更改的良好实践与应用程序设计的良好实践相同。您希望对体系结构进行分层，并最大限度地减少代码在每个依赖项上的广泛耦合，以便保持更改隔离，以便升级依赖项不会破坏应用程序的每个部分。接口代码，并将业务逻辑与基础架构代码分开。
对于次要升级（依赖项的升级版本），如果您有一套全面的单元测试来检测由于API更改而导致的故障，则会有所帮助。这是为什么它有时有助于编写表面上总是有效的琐碎测试的一个重要原因。一个例子是编写一个简单的JDBC单元测试来执行简单的查询。这似乎是浪费精力，直到你在数据库升级后发现JDBC驱动程序的运行时问题（这发生在我身上）。
对于较大的更改（如在Spring之类的框架的不兼容版本之间进行升级），如果您有一些自动化的功能或集成测试，或者至少具有QA人员可以运行以验证高级功能的功能规范，则会有所帮助。如果要升级的框架API不同，需要进行广泛的代码更改，则单元测试可能不再相关。
管理从一个依赖版本迁移到另一个版本的不兼容版本的实际战术部分实际上取决于您正在做什么。一个成熟的库将提供某种迁移路径，希望不会要求您重写所有内容。将与框架升级相关的代码更改与实现新功能相关的更改分开是一个好主意。这样一来，如果出现问题，您就会知道它与框架升级有关，而不是在实现新功能时出现的问题。
使得这么困难的部分原因是，在运行时，您的JVM中只能有一个特定依赖项版本，因此您必须立即更新所有代码。 OSGi通过允许在其中运行的不同OSGi包依赖于不同的依赖版本来解决此特定问题，因此您可以在运行时依赖于不同的依赖版本。这就是Eclipse在不破坏其他插件的情况下管理插件依赖的方法。