Средства и методы разработки

Механизм проверки соответствия набора фич: кто как делает, кто как думает? Это не соцопрос, это реальная проблема в моем проекте. Меня мучает такой вопрос: какие существуют наиболее правильные/элегантные/проверенные временем решения для проверки соответствия набора фич между несколькими компонентами в одной большой системе? Буду благодарен советам или хорошим ссылкам. Другими словами: пусть имеется прога с набором библиотек (больше 1 и даже 2) + к этому имеются подключаемые периферийные устройства со своими фичами. Весь этот зоопарк живет и развивается несколько лет. За это время в каждом отдельном компоненте появляются новые фичи/удаляются старые. Необходимо обеспечить способ гарантированной и достоверной проверки того, что включенные в случайном порядке компоненты могут/не могут работать. Есть еще случай универсальных либ, которые накапливают поддержку новых фич в других устройствах, но не удаляют поддержку старых для обеспечения обратной совместимости. Т.е. они при старте должны адаптироваться под конкретное подключенное устройство. В простом случае проблему можно как-то решить запросом и проверкой версий. Однако этот метод требует обновления адаптируемых библиотек, поскольку они могут все знать о версии 1.2.3 и не могут ничего априори предполагать о новой вышедшей версии 1.2.4 или 1.3.0 -- это может быть просто багфикс релиз, а может быть добавлена новая фича. Плюс встает в полный рост проблема, когда просто невозможно обновить универсальную либу у заказчика, потому что его система уже утверждена надзорным органом и грубо говоря "опломбирована". Плюс номера версий зачастую не столь прямолинейны как major.minor.build, часто это просто одно число типа 201089 (исторически сложилось). Проблема усугубляется тем, что данная система имеет несколько вариантов конфигурации/комплектации для разных заказчиков. Т.е. опять же проверка версий -- это не то решение, которое надо.