Организация работы с git submodules

О, спасибо за наводку, пошёл копаться

Основной аргумент — достаточно сырой код, который, вероятно, ещё не раз будет подвергаться рефакторингу, включая крупные изменения API (такие как переименования классов, перенос свойств/методов и т. п.). По крайней мере, я за неделю уже столкнулся с тем, что с переход от PR2 к PR3 был не безболезненный. Есть баги, которые сложно вылавливать, т. к. довольно много сгенерированного кода, который непонятно где (если только начал работать с фв) генерируется.

Второй — в связи с тем, что фреймворк в активной стадии разработки документации нормальной нет, а та что есть частично «out of date», как пишут в рассылке. То есть разработчику сложно будет использовать фреймворк как «чёрный ящик», надо будет подробно изучать его код, а где-то он будет изобретать велосипед, то есть реализовывать уже реализованные, но ещё не документированные возможности.

Ну и третий, как следствие первых два, увеличенное время разработки, как в связи с постоянными изменениями самого фреймворка (вы же не хотите, чтобы в вашем проекте была не самая свежая версия фв, которую, в том виде, в котором она есть, возможно исправлять никто не будет), так и в связи с тем, что разработчика хорошего знакомого с фв вряд ли найдёте, а значит время на изучение ему потребуется (оплачивать или нет это время — есть разные точки зрения, лично я считаю, что если на знакомом фреймворке проект можно написать за месяц, а на незнакомом за два, то оплата должна быть как за 1,5 месяца :) — компромисс между желаниями разработчика и заказчика).

Есть и плюсы: фреймворк реально шустрый; «тру» архитектура и самого symfony2 и дефолтной орм(sql СУБД)/одм (nosql — сейчас только mongodb, но мне её с лихвой хватает :) ) doctrine (используются многие паттерны архитектуры enterprise приложений, навскидку — сервисы, фабрики, единица работы, репозитории, инъекции зависимостей и т. д.), а значит модификация кода будет происходить довольно быстро; ориентирован на активное использование DDD, TDD и т. п.

В общем рекомендовал бы пока только для проектов, которые зарелизятся к концу года (когда должен выйти релиз symfony2), а то и позже, и сроки не жмут. И обязательно требовать от разработчика покрытия его кода тестами близкого к 100% (как минимум, 100% кода взаимодействующего с фреймворком), чтобы при изменении в API все проблемные места моментально выявлялись и исправлялись, поскольку из документации сейчас, по сути, только комментарии к коммитам

P.S. И тут Остапа понесло :)