如何使您的第三方库保持最新状态？

假设我有一个依赖于10个库的项目，并且在项目的主干中，我可以自由使用这些库的任何版本。因此，我从最新版本开始。然后，每个这些库每月平均更新一次。现在，要使行李箱保持最新状态，则需要每三天更新一次图书馆参考。

这显然太多了。尽管通常1.2.3版是1.2.2版的直接替代品，但如果不进行测试就不会知道。单元测试还不够；如果是DB /文件引擎，则必须确保它与使用较旧版本创建的文件一起正常工作，反之亦然。如果与GUI有关，则必须目视检查所有内容。等等。

您如何处理？一些可能的方法：

• 如果它还没有坏，那就不要修复它。只要您在应用程序中使用它时没有发现任何问题，就可以使用当前版本的库，无论库供应商多久发布一次更新。微小的增量更改只是浪费。
• 经常更新以使更改保持较小。由于无论如何都需要进行某天的更新，因此最好经常进行更新，以便在易于修复的情况下及早发现任何问题，而不是跳过多个版本并让潜在的问题积累。
• 介于两者之间。有一个甜蜜的地方吗？

我很震惊-确实感到震惊-这里的答案很多，说“除非必须，否则不要更新”。我已经做到了，尽管从短期来看它更容易，但是从长远来看，它就像地狱一样燃烧。比起偶尔的大更新，更频繁，更小的更新要容易得多，而且管理起来也容易得多，而且您可以早日受益于新功能，错误修复等。

我不认为库更改比代码更改更难测试。都是一样的-您正在更改代码库，需要在提交之前进行验证，在发布之前进行更深入的验证。但是您必须已经有执行此操作的流程，因为您正在更改代码！

如果您要进行大约两到四周的迭代工作，我建议您将每个迭代任务一次更新一次库，并在开始后尽快进行，这时的工作要比迭代前轻松一些。截止日期，该项目具有吸收变更的更多能力。让某人（或者一对，如果要进行配对编程）坐下来，查看哪些库已更新，然后尝试将每个库引入并进行重建和测试。也许每次迭代都要花半天到一天的时间。如果一切正常，请检查更改（我假设您像我们一样将库保留在源代码控制中；如果不确定，我不确定如何以受控方式传播更改）。如果您拥有自动化测试，那显然比完全手动进行测试要容易得多。

现在，问题是，如果更新破坏了您的工作，您是花时间修复它还是将其遗忘？我建议倾向于后者。如果可以在一小时内将其修复，请执行此操作，但是如果要进行大量更新工作以进行集成，则将其作为其自己的开发任务来进行，并与其他任何方法一样进行评估，确定优先级和计划。机会是，除非它带来一些非常关键的修复或改进，否则优先级将很低，您将永远无法解决。但是，您永远不知道，等到下一个迭代更新日轮到时，问题可能会自行解决。即使没有，至少现在您也知道更新路径上有一个障碍，它不会让您感到意外。

如果您不进行该长度的迭代，那么我会设置某种独立的更新时间表-不超过每月一次。您是否还有其他项目节奏可以配合使用，例如每月状态审查或建筑委员会会议？发薪日？比萨之夜？满月？无论如何，您都需要找到比传统发布周期短得多的东西，因为尝试每6-18个月一次更新所有内容会很痛苦且令人沮丧。

不用说，如果您在发布前进行稳定化分支，则不会将此策略应用于它们。在那里，您只需要更新库即可获取关键修复程序。

我评估。

• 首先，我寻找我们针对该库提出的错误，并查看它们是否已修复。
• 其次，我在库中寻找其他任何我们可以从中受益的错误修复（也许是一些可能的极端情况）。
• 第三，我在lib / API中寻求改进，然后研究更改我们的代码以利用它的好处以及利益的权衡。过去，我经常在没有实际使用它们的新功能的情况下升级库，真的很傻！

然后，我权衡所有这些，以反对保留现有的lib。

始终进行测试-希望您的单元/集成测试将确保不会发生重大退化。

第三方库的主要问题在于，在更新应用程序之前，您需要对其进行重新测试，然后才能投入生产。因此，除非您报告了一个需要更新库的错误，否则在您有时间进行完整的质量保证周期之前，请不要触摸它们。

通常在发布新版本时完成。

但是，我建议您有一个用于连续构建的测试套件，该套件允许您更新开发分支中的库并自动进行。这将确保您在损坏时及早发现，以便可以向项目提交错误报告。

如svn供应商分支中所述。当您长时间使用开放源代码的第三方库并进行了更改以根据需要进行调整时，此处描述的过程非常有用。

我会考虑在发布之前或发布之后更新项目的所有库。但是，如果您依赖于10或15个以上的库，这可能会失控，在这种情况下，某种更新检查机制将大有帮助。这样做的好处是您有时间专门用于测试库，并且可以一次性解决所有问题。您也不必经常跟踪每个库的更新，只需检查某一天的任何更新即可。

我什至也反对在dev分支中使用任何类型的自动更新功能。如果在我中途由于图书馆自动更新而导致项目中断，或者我突然因为使用刚刚被其他东西取代的API而收到折旧警告，那将是令人沮丧的。

您必须问，您真正想要更新的内容是什么？大多数安全修复程序实际上都是琐碎的补丁，形式为修复程序：

• 发生一个错误，可以将任意代码复制到缓冲区中未使用的空间
• 悬空指针或其他触发未定义但（确定）确定性行为的指针
• 允许某种DoS的错误
• 容易使窥探私有数据的错误
• 数学失误
• 维护人员接触他们不应该使用的东西（Debian SSL错误，有人吗？）

如果您查看过去五年中的大多数CVE，则如果使用开放库（通常希望如此），则修复它们的修补程序通常非常琐碎。

然后，您可能需要实际的错误修复，但也许您已经自己修复了。如果没有损坏，请不要修复。

最后，您具有新功能..甚至不推荐使用的功能。您需要仔细检查这些发行说明和差异。即使它们破坏了许多其他内容所依赖的API，您也可以使用它们吗？如果是，那么是时候进行手术了。如果否，樱桃选择您想要的并继续。

有些人可能不同意我的观点，但是我拒绝使用没有源代码的库。

它的变化取决于诸如库，它们的用途，它们在代码中的普及程度，执行升级的成本（在时间和金钱方面）之类的事情。

理想情况下，您始终会始终拥有最新版本，但是如果新版本不向后兼容，那又该怎么办？您可能需要搁置该更新以供将来发行，直到可以仔细处理更改为止。行为可能会有一些细微的变化（例如“现在您需要在调用方法Y之前设置属性X，否则会发生缓慢的内存泄漏”），这在测试中很难验证。

另一方面，新版本可能具有一些严重的安全修复程序，因此您也必须考虑到这一点。

简短版本：视情况而定。

这将取决于您的发行表。

但是我的建议是在所有开发人员计算机上安装一组库。如果您希望将其称为某种黄金标准，则可以开始对该版本的开发。

仅在部署了发行版并且您处于发行后阶段之后，才重新评估您的库，它们的版本和功能。如果他们提供了一些重大改进或新功能，则在下一个开发周期开始之前进行安装。

只有在部署软件之前必须解决的主要问题或错误时才安装新版本。

这将意味着您将错过某些版本，但它应该可以省去一些麻烦和版本控制问题，使您可以专注于开发应用程序。

颠覆外部

该功能的优点是您可以指定所需的修订版。

请注意，如果您有很多外部设备，更新速度会变慢。

我目前正在设置类似的东西：

• 我的应用程序的每个扩展都有1个商业回购
• 收集了多个第三方库的特定版本的商业回购
• 用于图形资源/作品的SVN存储库（但可能会更改为其他内容）
• 我的应用程序的Mercurial回购，它使用Mercurial Subrepos功能来使用特定版本的第3个pary回购，以及一些基本扩展

现在，当我需要处理不是“基本”的扩展（隐式包含在应用程序存储库中作为子存储库）时，我只需在扩展文件夹中克隆存储库，然后让CMake生成整个应用程序的项目和解决方案。

这样，我可以：

• 更改克隆中的第3方，检查其是否与该应用程序兼容，将其推入第3个pary repo中，然后将应用程序repo的subrepo版本更新为新的3rd party repo版本
• 独立地，全部地或单独地选择扩展来工作
• 不必担心必须将项目链接在一起，这是由Cmake完成的，只需将项目子存储库与整个应用程序存储库一起扫描即可。

在这个组织上还没有很多经验，但是我认为这很有用。

如果您的软件对安全性至关重要，则必须尽快更新，没有任何借口。您不希望在图形库中出现一个小错误以使整个程序容易受到攻击。

否则，当库成熟时，它是“如果它没有损坏，请不要修复它”。为了我。迟早，我可能需要更高版本的功能，别无选择，只能进行更新，但是直到那时，这种努力很难证明是正确的。另一方面，当我使用相对较新的lib或框架（例如Grails或ExtJS）时，我会保持最新，因为这些产品尚未完全成熟，因此更新很可能可以救我从遇到这些错误之一后，更高版本已修复。

我使用NuGet使我的第三方库保持最新。

当朋友，同事或博客通知我我的第三方DLL之一已过期时，NuGet可以非常轻松地对其进行更新。