情况：
我们的首席架构师创建了一个 C++ 库，旨在作为我们工作领域的“运行时”（它们实际上是几个库 - 想想 sdl、sdl_net、sdl_ttf，但是具有 C++ 接口，并且它们总是应该一起使用，即使您可能只需要其中一个）。
也就是说，这些库链接到一堆 CRUD 应用程序、其他（更具体的）库（想想基于 sdl 的 sprite 库）和更大规模的应用程序（客户端/服务器、远程 GUI）。
问题：
由于一系列原因（当然，缺乏时间，作为其中之一），“运行时”库仍然会发生变化。可能会引入新类，可能会将现有类拉入类层次结构，可能会更改方法参数等等。由于没有 ABI，链接运行时的代码会中断，并且在没有正确版本控制的情况下动态链接时，生产软件会崩溃。
拒绝的解决方案：
- 运行时库的更改应引入新版本。交付时链接的二进制文件
myrt.so.1仍然有效myrt.so.2，因为myrt.so.1不打算删除（一段时间）。
拒绝理由：会有很多新的库版本“污染”生产环境。最坏的情况是每个二进制文件都有自己的myrt版本。
- 静态链接。
拒绝的原因：连同明显的膨胀，上面的最后一个陈述实际上也适用于这里。
- 保留两个
myrt版本并重建依赖关系，否则在发布新的myrt.
拒绝的原因：没有时间测试所有依赖项的功能（只有很少的自动测试）并且发布未经测试的二进制文件的风险被认为太高了。
问题：
我们还能做什么？您是否认为有任何方法可以通过处理拒绝声明来恢复提议的解决方案之一？
它可能是在纠正症状而不是原因（缺乏自动测试，缺乏实际创建稳定 API 的资源等）。老实说，我没有看到解决更大问题的方法，尽管已经采取了更好的测试步骤。