> "велосипед" который будет обновляться самой командой в соответствиями с требованиями проекта?
Проблема в том, что требования бизнес-процесса всегда имеют больший приоритет перед необходимостью технической модернизации. И в реальности внутренний фремворк никогда не обновляется (ну, если только конечно вы не Баду с 100500 девопсов), и через пару лет разработчики начинают чувствовать себя питекантропами.
Следует понимать, что используя мейнстримный фремворк, вы получаете обновления на халяву. Обновления, над которыми работают тысячи людей - ресурс, которого у коллектива системы "междусобочик" никогда не будет.
> Но что если новая версия очень сильно отличается от старой, придется проделать много работы по переделке большого проекта на новую версию.
Это значит, что фреймворк использовался только для украшения, а бизнес-логика писалась по-старинке, овнокодом.
Мы месяц назад поменяли мажорную версию Симфони, с 2.3 на 3.2. Переделки потребовались, но чисто механические, по замене нескольких устаревших функций.
Достаточно следовать рекомендованным практикам, использовать рекомендованные инструменты и апгрейд не будет настолько болезненным.
Плюс я считаю, что болезненность апгрейда в любом случае преувеличена, и несравнима с переездом с самопала.
> Как обычно поступают команды, когда используется сторонний фреймворк, постоянно обновляют его версию в проекте или остаются на старой версии?
Хотя бы за мажорной версией следовать необходимо.
Средний
