Symfony Миграция с 2.8 на 3/3.1

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Народ, кто что может сказать по сабжу, насколько сложно?

Ситуация такая: надо внедрять фреймворк в enterprise SAAS. Cегодня php еще 5.4, то есть сходу взять symfony 3 нельзя, у нее минимум 5.6.
Но 7ку тоже пробиваю, и через год таки хочется перейти на Symfony 3.3 LTS, когда она появится.

Стоит ли щас брать 2.8, а потом мигрировать на 3, или сначала поднять php до 5.6, что займет месяца два, а Симфони начинать лучше с 3, чтобы не переписывать?

По yii, например, я знаю, что мигрировать с 1 на 2 нельзя.
 
Последнее редактирование:

keltanas

marty cats
Судя по этому http://symfony.com/doc/current/contributing/community/releases.html#version-history Symfony 3.1 LTS не появится. Ближайший LTS - это 3.4. Она выйдет в ноябре 2017.

В данный момент 2.8 на все несовместимости с 3.0 кидает ошибку типа E_USER_DEPRECATED. Писать код в стиле 3.0-3.1 можно (и нужно) и на 2.8. Структура каталогов легко переопределяется (но, лучше это делать сразу). Да и конец поддержки 2.8 обещают к ноябрю 2018. К этому времени, скорее всего выкатят доку по миграции, если в этом будет необходимость.

В общем я бы пока не стал спешить. Особенно вспоминая, как раньше с каждым релизом (до 2.3) ломалась обратная совместимость и приходилось рефакторить весь код каждые пол года.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
не спешить с чем именно 0 с 3-кой?
ноябрь или май - неважно, когда-нибудь, вопрос в том, что выбрать сейчас, а в 3ке мне нравится что логирование по PSR3, мне нужна унификация в нескольких проектах

> Ближайший LTS - это 3.4. Она выйдет в ноябре 2017.
значит, wikipedia неактуальная
 
Последнее редактирование:

keltanas

marty cats
Symfony 3.0: The roadmap - November 11, 2014 - посмотрел по диагонали, там уже есть неточности: "So, Symfony 3.0 will be released in November 2015 and the first 3.x long term release will be 3.3 to be released in May 2017.". Кодекс - это свод рекомендаций, а не законов.
Симфони обоих версий использует Monolog, который имплементирует Psr\Log\LoggerInterface. Если твои компоненты будут хотеть LoggerInterface, а не конкретную реализацию, то все будет унифицировано.
 

AmdY

Пью пиво
Команда форума
Надо смотреть по бандлам, которые планируете использовать. какая у них совместимость с 3-кой и php7, а то я встречал уже проблемные с валидаторами True на 7-ке.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@AmdY, без сторонних бандлов. Даже не уверен насчет доктрины. Для меня главное - архитектура и базовая инфраструктура вроде монолога, SOAP, XML
 

Вурдалак

Продвинутый новичок
Там по части PSR-3 лишь косметические изменения внутренностей HttpKernel, где у них раньше был свой интерфейс. На пользовательский код это никак не влияет.
 

keltanas

marty cats
Ну кстати, Symfony 3.2 все еще готова запускаться на PHP 5.5. https://github.com/symfony/symfony/blob/master/composer.json
По моему мнению ее отличие в основном в некотором упрощении, снижении порога вхождения и добавления сахара для различного рода yii- и laravel- водов.
Сахар - он, конечно, вкусный. Но, от него толстеют.
По новостям можно отследить все изменения, которые вводились по мере развития (или деградации?) http://symfony.com/blog/ в 3й версии.
 

AmdY

Пью пиво
Команда форума
Ну, если стороннего ничего не используется, то тогда лучше брать версию посвежее, по ходу регрессии будут появляться не часто и фиксить не страшно. А если даже доктрину не планируешь юзать, то тогда точно лучше по третей ветке идти, там можно разные воркфлоу настраивать и облегчать ядро.

Сахар - он, конечно, вкусный. Но, от него толстеют.
Толстеют не от самого сахара, а от непотраченых углеводов, а с доктриной это гарантировано, т.к. вместо баскетбола приходится возиться со странными багами вроде подобного http://stackoverflow.com/questions/36252095/payum-bundle-symfony-2-extended-payment-data и такое гавно на каждом шагу, понятно почему у вас использование бандлов не приветствуется.
 

Вурдалак

Продвинутый новичок
Толстеют не от самого сахара, а от непотраченых углеводов, а с доктриной это гарантировано, т.к. вместо баскетбола приходится возиться со странными багами вроде подобного http://stackoverflow.com/questions/36252095/payum-bundle-symfony-2-extended-payment-data и такое гавно на каждом шагу, понятно почему у вас использование бандлов не приветствуется.
По ссылке же написано в чём проблема, Doctrine к этому отношения не имеет.

Если говорить о таких бандлах вообще, то здесь ровно те же проблемы, что с CMS.
Это куски бизнес-логики, которые попытались абстрагировать как можно сильнее, чтобы можно было «гибко» конфигурировать.
На самом же деле, вместо траты времени на собственные модели, разработчик будет тратить время на конфигурацию и отладку чужого говнокода, а также будет иметь ограничения на функциональность, которая и будет упираться в эти бандлы.
Любишь медок, люби и холодок.
 

AmdY

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

Вурдалак

Продвинутый новичок
Это как раз проблема доктрины, которая имеет три кэша, которые чистятся разными командами, и не чистятся когда надо, возлагая все грабли на разработчиков.
А ты точно читал то, что по ссылке, которую кинул сюда? Какое отношение имеют кеши к отсутствию зарегистрированного типа из JMSPaymentBundle?
 

fixxxer

К.О.
Партнер клуба
Кэши там никаким местом вообще. В схеме задан кастомный тип, реализация которого отсутствует, потому что чувак вынес соответствующий бандл. Логично, что ничего не работает.
 

keltanas

marty cats
Кэши там никаким местом вообще. В схеме задан кастомный тип, реализация которого отсутствует, потому что чувак вынес соответствующий бандл. Логично, что ничего не работает.
Поскольку для работы с доктриной нужно явно декларировать маппинг данных (в отличии от yii или eloquent), и этот маппинг может задаваться различными способами (annotation, yml, xml), то, чтобы его каждый раз не парсить, доктрина его кеширует (ваш кэп). Вполне возможно, что чувак залил на продакшен обновление с удаленным бандлом, в кеш маппинга не очистил. А для скорости, если dev режим отключен, то актальность кеша не проверяется.
Чуваку надо было в свой деплой-скрипт чистку этого кеша добавить. А чтобы знать это, надо было документацию читать.

Это как раз проблема доктрины, которая имеет три кэша, которые чистятся разными командами, и не чистятся когда надо, возлагая все грабли на разработчиков.
Доктрина здесь все правильно сделала (см. выше). Это не Вордпресс, это Спарта.
 

fixxxer

К.О.
Партнер клуба
Спасибо, кэп! :)

Ай, если это на продакшене, то это вообще фейспалм какой-то. :)

При каждом деплое вообще лучше иметь каждый раз новый путь к кэшам.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
понятно почему у вас использование бандлов не приветствуется.
просто каждый бандл надо аппрувить индивидуально у 10 человек, это enterprize,
а от симфони нужен только application design c DI и немного инфраструктурных вещей, чтобы сдерживать народ от return new exception
 
Последнее редактирование:

scorpion-ds

Новичок
Я довожу до версии 2.8, но мигрировать старые проекты не решаюсь, мало ли где забуду "формочку" поправить ..., новые проекты только SF3.
 
Сверху