Комментарии (8)

1. 

   Metus

   01.02.2016 09:19

   #8757471

   Что-то laravel со своим расписанием релизов и LTS-версиями стал похож на ubuntu. Нехорошо это.

   
   

   1. 

      Fesor

      01.02.2016 10:56

      #8757511

      +1

      Больше анархии, хаоса и стихийной разработки? Проекты типа такого должны быть с предсказуемым графиком релизов.

      
      

      1. 

         Metus

         01.02.2016 11:34

         #8757541

         +2

         Проекты типа такого должны выпускаться тогда, когда они готовы выпускаться, а не по графику — не пирожки всё таки пекут и не пятилетки за 4 года делают.
         
         И та же убунта это отлично показала своими глючащими раскладками и прочими артефактами. Так показала, что все, кто не ищут приключений, пользуются исключительно LTS-версиями. Некоторые даже не сразу, а после первого патча.
         
         Анархию и хаос скорее вызовет факт что к концу этого месяца должны 100% выкатить релиз.
         

         
         

         1. 

            Metus

            01.02.2016 11:47

            #8757557

            +4

            Добавлю ещё.
            
            Мне как разработчику на Laravel не обязательны версии каждые 6 месяцев. Мне, как потребителю, нужны стабильные релизы, а выходят они по расписанию или с задержками — не важно. Свои дедлайны разработчики фреймворка могут хранить при себе.
            
            Подобное расписание привлекает неофитов, которые выбирают фреймворк и видят, что новая версия вышла 3-4 месяца назад, после чего бегут туда.
            
            2 версии в 1 год — это исключительно маркетинг для привлечения большего количества разработчиков — не более.

         
         

         1. 

            Fesor

            01.02.2016 12:24

            #8757583

            +2

            Проекты типа такого должны выпускаться тогда, когда они готовы выпускаться, а не по графику

            
            
            Проекты такого типа должны выпускаться строго по графику что бы не задерживать выход новых фич. Я не хочу ждать пока авторы допилят фичу Б хотя мне нужна фича А, а dev-master использовать как-то не гуд.
            
            Это не означает что авторы должны пытаться впихнуть цикл разработки фич в этот график, туда просто попадают те фичи которые успели сделать. Обратная совместимость в минорных релизах все же должна сохраняться, а чистить фреймворк раз в год от депрекейтед функционала тоже весьма и весьма полезно.
            
            

            Анархию и хаос скорее вызовет факт что к концу этого месяца должны 100% выкатить релиз.

            
            В таком случае это плохо говорит о контрибьюторах, которые форсят фичи что бы вклиниться в релиз. Обычно за всем этим жестко следит команда разработчиков.
            
            То что попало в мастер должн быть законченной фичей, с сохранением обратной совместимости относительно текущей ветки. А по рассписанию или абы как теги расставляются — это не важно. Просто по рассписанию проще отслеживать.

1. 

   cyberorg

   01.02.2016 11:29

   #8757535

   +1

   Майка зачётная, надо будет потроллить своих знакомых ПХПшников.
   

1. 

   Standfest

   02.02.2016 12:18

   #8758615

   +1

   Внедрение зависимостей без контейнера — Пример использования трейта вместо контейнера.

   
   Очень плохой пример использования трейта. В указанном примере автор статьи якобы избавляется от контейнера и внедряет зависимости через трейт. Но на самом деле зависимости не внедряются, он сам просит их у трейта, который в свою очередь их создает. По факту это то же самое, что сделать в исходном классе метод:
   

   function buildMyDependency() { return new MyDependency(); }
   

   
   Плохо это тем, что это 1) не внедрение зависимости, а ее создание 2) при юнит тестировании нет возможности смокать эту зависимость, следовательно метод buildMyDependency нормально протестировать невозможно. Единствнное остается смокать сам метод buildMyDependency(), а сама логика этого метода останется непокрытой.