Comments 8
Что-то laravel со своим расписанием релизов и LTS-версиями стал похож на ubuntu. Нехорошо это.
Больше анархии, хаоса и стихийной разработки? Проекты типа такого должны быть с предсказуемым графиком релизов.
Проекты типа такого должны выпускаться тогда, когда они готовы выпускаться, а не по графику — не пирожки всё таки пекут и не пятилетки за 4 года делают.
И та же убунта это отлично показала своими глючащими раскладками и прочими артефактами. Так показала, что все, кто не ищут приключений, пользуются исключительно LTS-версиями. Некоторые даже не сразу, а после первого патча.
Анархию и хаос скорее вызовет факт что к концу этого месяца должны 100% выкатить релиз.
И та же убунта это отлично показала своими глючащими раскладками и прочими артефактами. Так показала, что все, кто не ищут приключений, пользуются исключительно LTS-версиями. Некоторые даже не сразу, а после первого патча.
Анархию и хаос скорее вызовет факт что к концу этого месяца должны 100% выкатить релиз.
Добавлю ещё.
Мне как разработчику на Laravel не обязательны версии каждые 6 месяцев. Мне, как потребителю, нужны стабильные релизы, а выходят они по расписанию или с задержками — не важно. Свои дедлайны разработчики фреймворка могут хранить при себе.
Подобное расписание привлекает неофитов, которые выбирают фреймворк и видят, что новая версия вышла 3-4 месяца назад, после чего бегут туда.
2 версии в 1 год — это исключительно маркетинг для привлечения большего количества разработчиков — не более.
Мне как разработчику на Laravel не обязательны версии каждые 6 месяцев. Мне, как потребителю, нужны стабильные релизы, а выходят они по расписанию или с задержками — не важно. Свои дедлайны разработчики фреймворка могут хранить при себе.
Подобное расписание привлекает неофитов, которые выбирают фреймворк и видят, что новая версия вышла 3-4 месяца назад, после чего бегут туда.
2 версии в 1 год — это исключительно маркетинг для привлечения большего количества разработчиков — не более.
Проекты типа такого должны выпускаться тогда, когда они готовы выпускаться, а не по графику
Проекты такого типа должны выпускаться строго по графику что бы не задерживать выход новых фич. Я не хочу ждать пока авторы допилят фичу Б хотя мне нужна фича А, а dev-master использовать как-то не гуд.
Это не означает что авторы должны пытаться впихнуть цикл разработки фич в этот график, туда просто попадают те фичи которые успели сделать. Обратная совместимость в минорных релизах все же должна сохраняться, а чистить фреймворк раз в год от депрекейтед функционала тоже весьма и весьма полезно.
Анархию и хаос скорее вызовет факт что к концу этого месяца должны 100% выкатить релиз.
В таком случае это плохо говорит о контрибьюторах, которые форсят фичи что бы вклиниться в релиз. Обычно за всем этим жестко следит команда разработчиков.
То что попало в мастер должн быть законченной фичей, с сохранением обратной совместимости относительно текущей ветки. А по рассписанию или абы как теги расставляются — это не важно. Просто по рассписанию проще отслеживать.
Майка зачётная, надо будет потроллить своих знакомых ПХПшников.
Внедрение зависимостей без контейнера — Пример использования трейта вместо контейнера.
Очень плохой пример использования трейта. В указанном примере автор статьи якобы избавляется от контейнера и внедряет зависимости через трейт. Но на самом деле зависимости не внедряются, он сам просит их у трейта, который в свою очередь их создает. По факту это то же самое, что сделать в исходном классе метод:
function buildMyDependency() { return new MyDependency(); }
Плохо это тем, что это 1) не внедрение зависимости, а ее создание 2) при юнит тестировании нет возможности смокать эту зависимость, следовательно метод buildMyDependency нормально протестировать невозможно. Единствнное остается смокать сам метод buildMyDependency(), а сама логика этого метода останется непокрытой.
Sign up to leave a comment.
PHP-Дайджест № 78 – интересные новости, материалы и инструменты (18 – 31 января 2016)