Здравствуйте, Aquary, Вы писали:

A>Начну с конца
B_>>Просто странно, что для задачи номер один я не нашел ни одного готового решения в инете.
A>Потому что из все массы производимого ПО доля программных комплексов (когда несколько независимых аппликух работают вместе) — очень мал. И чем больше приложений в комплексе, тем мЕньший процент их "встречаемости". Соответсвенно, насколько велика вероятность встретить подобный спец. софт, написанный для ещё более "спец." софта? Эк завернул...

Вероятность стремится к нулю, за пару дней поиска в интернете ни одного рельного ПО для подобной проблемы

B_>>1. Все верно, приложения разрабатываются независимо и имеют разную кодовую базу (.NET WinForms, ASP.NET WebServices, C++/MFC). Совместимость отслеживается по нескольким направлениям:

B_>>

B_>>1. По структуре БД.
B_>>2. По интерфейсам веб сервисов.
B_>>3. По данным на диске (при установке любого приложения на диске создается определенная файловая струкутра общая для совместимых приложений).
B_>>4. По структуре данных (через веб сервисы и файловую систему приложения обмениваются XML файлами)
B_>>

A>2. изменить организацию выпуска релизов софта, т.е. его версий.

A>That's it при обновлении софта у заказчика разворачиваются не много мелких приложений, а 3 группы — не больше, но и не меньше. Причем зависимость между группами — однозначная.
A>Как только обновляется версия одного из приложений — обновляется и версия его группы. А имя малькое описание — кто от кого зависит — легко узнать кто ещё зависимый должен обновиться, а кого можно не трогать.

A>Очень важн вести release notes как каждого приложения, так и групп. Каждый выпуск релиза сопровождается релизнотами, где прописывается — от чего оно зависит.

A>По большому счету, таким методом можно перейти от большого количества конкретных аппликух — к абстрактным модулям.

A>Кстати, этот же метод позволит упростить процесс выпуска релизов и их тестирование — сначала будут выпускать приложение, тестироваться само по себе, потом внутри модуля, затем — тестирование межгрупповое.

Этот вариант сейчас и видится наиболее подходящим для решения проблемы, так как на самом деле все эти приложения группируются по определенным признакам, но пока это больше используется отделом маркетинга для продвижения продуктов , а не для SCM.

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

Спасибо, за развернутый ответ.