Комментарии 9
И выполням команду:
И все хорошо ровно до того момента, пока мы не понимаем что там же еще целый ворах бандлов у нас в проекте юзается! И как это не смешно, парочка уже настолько старые, что их авторы удалили репозитории!
Мне повезло, бандлы, которые использовались в проекте все еще существуют и развиваются. Некоторые поменяли свои названия или были разбиты на более мелкие бандлы. Конечно, если репозиторий бандла более не существует, то логично функицонал, который использовался с этим бандлом, переписать на другой, более новый, либо оставить старую версию прямо в папке vendors. Если мы будет подтягивать зависимости composer'ом, то папку этого бандла он не затрет.
Браво! Безумству храбрых поем мы песню!
Если проект активно развивается, мне кажется его основа тоже не должна быть 3-4 летней давности. Правда заказчику пофиг какое там симфони под капотом… Приходится искать баланс между качеством — временем внедрения и стоимостью ))
Если проект активно развивается, мне кажется его основа тоже не должна быть 3-4 летней давности. Правда заказчику пофиг какое там симфони под капотом… Приходится искать баланс между качеством — временем внедрения и стоимостью ))
Породируя анекдоты про эстонцев «Что-то симфони обновилось...»
Такое обновление происходит только в случае когда проект воскрес через 3-4 года после того как его забросили или же в еще более тяжелом случае, когда предыдущие разработчики были приверженцами «работает не трогай» в терминальной стадии.
Мне кажется что в конце пропущена фраза «а потом смотрим что из проекта еще вдруг случайно заработало», потому что количество изменений которые произошли просто огромно
Такое обновление происходит только в случае когда проект воскрес через 3-4 года после того как его забросили или же в еще более тяжелом случае, когда предыдущие разработчики были приверженцами «работает не трогай» в терминальной стадии.
Мне кажется что в конце пропущена фраза «а потом смотрим что из проекта еще вдруг случайно заработало», потому что количество изменений которые произошли просто огромно
На сколько понимаю, возможные сложности с обновлением фреймворка и стали причиной, по которой отказались от схемы «один фреймворк на всю систему» (так было в 1.х) в пользу «каждому проекту свой фреймворк». Косвенно это подтверждает и версионность документации. Что касается проблемы с совместимостью сторонних бандлов, то всегда можно склонировать, прописать в зависимости и развивать свою версию (а благодаря git изменения оригинального можно подтягивать по мере необходимости).
Не «каждому проекту свой фреймворк» а «для каждой задачи свой компонент». Все же есть разница. Это позволяет проектировать более гибкую систему, такую систему проще поддерживать. less is more как говорится. Обновление отдельных компонентов так же проще чем обновление всего фреймворка, но это как следствие а не основная причина.
Я имел в виду то, что версия 1.х устанавливалась как расширение php и использовалась совместно всеми проектами на данном сервере. В версии 2.х от этого отказались, и для каждого проекта используется свой экземпляр. Фабиэн писал о том, что так сделали именно для того, чтобы не было проблем с версиями. Какая проекту версия нужна, такая в нем и содержится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция с Symfony 2.0 до 2.6