Как бороться с нестабильным API глобально используемого фреймворка

Ситуация:

Наш главный архитектор создал библиотеку C ++, которая предназначена как «среда выполнения» для нашей рабочей области (на самом деле это несколько библиотек — подумайте о sdl, sdl_net, sdl_ttf, однако с интерфейсом C ++, и их всегда следует использовать в целом, даже если вам может понадобиться только один из них).

То есть эти библиотеки связаны с кучей приложений CRUD, другими (более конкретными) библиотеками (например, спрайтовой библиотекой на основе sdl) и более масштабными приложениями (клиент / сервер, удаленный графический интерфейс).

Проблема:

По ряду причин (конечно, из-за нехватки времени, будучи одной из них) библиотека «времени выполнения» все еще может быть изменена. Могут быть введены новые классы, существующий класс может быть добавлен в иерархию классов, параметры метода могут измениться и так далее. Поскольку ABI отсутствует, код, связывающий среду выполнения, будет нарушен, а производственное программное обеспечение аварийно завершит работу при динамическом связывании без правильного управления версиями.

Отклоненные решения:

• Изменения для библиотеки времени выполнения должны представить новую версию. Двоичные файлы, ссылающиеся на myrt.so.1 все еще будет работать, когда myrt.so.2 поставляется с myrt.so.1 не предназначен для удаления (в течение некоторого времени).

Причины отказа: будет много новых версий библиотек, «загрязняющих» производственную среду. В худшем случае каждый двоичный файл имеет свой myrt версия.

• Статическое связывание.

Причина отклонения: вместе с очевидным раздуванием последнее утверждение сверху практически применимо и здесь.

• Держи наверное два myrt версии и перестроить зависимости, которые иначе сломались бы при отправке новой партии myrt,

Причина отклонения: нет времени для проверки работоспособности всех зависимостей (автоматического тестирования мало), а риск отгрузки непроверенных двоичных файлов считается слишком высоким.

Вопрос:

Что еще мы могли сделать? Видите ли вы какой-нибудь способ возродить одно из предложенных решений, занявшись заявлениями об отказе?

Вероятно, это лечит симптомы, а не причину (отсутствие автоматического тестирования, нехватка ресурсов для создания стабильного API и т. Д.). Честно говоря, я не вижу выхода из более серьезных проблем, хотя сделаны шаги к лучшему тестированию.