我从事一个使用多个开源 Java 库的项目。当这些库的升级出现时，我们倾向于遵循保守的策略：
我们遵循这个策略是因为我们通常没有时间放入新库并彻底测试整个应用程序。（就像许多软件开发团队一样，我们几个月前承诺的功能总是落后于计划。）
但是，我有时想知道这种策略是否明智，因为库升级通常会带来一些性能改进和大量错误修复。（即“谁知道呢，也许事情会以我们无法预见的方式更好地工作......”）
当您在项目中做出这些类型的决策时，您使用什么标准？
重要提示：避免技术债务。
“如果它没有损坏，就不要升级”是一项疯狂的政策，它会导致软件如此损坏，以至于没有人可以修复它。
轻率、未经测试的更改是一个坏主意，但不如累积技术债务那么糟糕，因为它在短期内看起来更便宜。
获得一个“夜间构建”过程，这样您就可以持续测试所有更改——您的以及您所依赖的包。
在您拥有持续集成流程之前，您可以按季度发布主要版本，其中包括基础架构升级。
避免技术债务。
我已经学到了足够的教训来做以下事情：
编辑：我想再添加一个至少同样重要的项目，也许比其他项目更重要。
一种方法是将您使用的开源库置于您自己的源代码控制之下。然后定期将上游更改合并到您的下一个发布分支中，或者如果它们是安全修复，则更快地合并，并运行您的自动化测试。
换句话说，使用与内部编写的代码发布周期相同的标准来决定是否使用上游更改。将开源开发人员视为您的虚拟开发团队的一部分。无论如何，情况确实如此，这只是您是否选择将其视为您的开发实践的一部分的问题。
虽然您不想仅仅因为有新版本而升级，但还有另一个考虑因素，那就是旧版本的可用性。我在尝试构建开源项目时遇到了这个问题。
我通常认为忽略库的新版本（因为它没有任何有趣的功能或改进）是一个错误，因为有一天你会发现这个版本对于迁移到下一个版本是必要的你可能想升级到。
所以我的建议是仔细检查新版本中的变化，并考虑这些变化是否需要大量测试，或者很少。
如果需要进行大量测试，最好在软件的下一个版本（主要版本）（例如从 v8.0 迁移到 v8.5 时）升级到较新的库。发生这种情况时，我想还有其他重大修改，因此进行了大量测试。
我不想让版本在依赖库上落后太多。除非已知安全或性能问题，否则大多数库最多可以使用一年。 有已知安全问题的库是刷新的必备。
我会定期下载每个库的最新版本并使用它们运行我的应用程序单元测试。如果它们通过了，我会在我们的开发和集成环境中使用它们一段时间，并在我满意它们不糟糕时推动 QA。
上述过程假设 API 没有显着变化。如果我需要重构现有代码只是为了使用更新的库版本，那么所有的赌注都没有了。（例如 Axis 1x vs. 2x）然后我需要让管理层参与来做出分配资源的决定。在计划对遗留代码进行重大修订之前，这种更改通常会有所不同。
一些重要的问题：
除非按照上述标准升级看起来很糟糕，否则最好继续使用它，如果您有任何问题，请恢复到旧版本。