Yii 2 собирается разделить репозиторий
21 марта 2015
Для ускорения процесса релизов и того, чтобы придать официальным расширениям большую независимость мы думаем разделить расширения и шаблоны приложений на отдельные проекты GitHub. Ниже приведён предварительный план. Прежде чем что-либо менять мы хотели бы услышать ваше мнение и возможные предложения. Спасибо!
UPD: отклик был положительный, разделили.
Организация проекта
Отделить официальные расширения и шаблоны приложений от основного кода в отдельные независимые проекты GitHub.
- Каждое расширение или приложение продолжит использовать то же имя для сохранения обратной совместимости. Например, расширение
yii2-gii
будет разрабатываться в проектеyiisoft/yii2-gii
. - Документация переедет в директорию "docs” того же проекта. Документация по API будет генерироваться автоматически при релизе расширения или шаблона приложения.
- Тесты переедут в репозитории расширений в директорию "tests".
- Переводы сообщений и другие мета-данные переедут в репозиторий расширения.
- Issue переедут в каждое отдельное расширение.
- Релизы будут независимы от основного фреймворка.
- Каждое расширение или приложение продолжит использовать то же имя для сохранения обратной совместимости. Например, расширение
Проект “yii2” будет использоваться для:
- Ядра фреймворка.
- Полного руководства. Руководства по отдельным расширениям переедут в проекты расширений. Документация по API будет генерироваться при релизе ядра фреймворка.
- Тесты для ядра фреймворка.
- Инструменты для сборки и внутренняя документация.
Для поддержания обратной совместимости будет, как и ранее, делаться subsplit из "yii2" в "yii2-framework”.
Issue ядра фреймворка будут в проекте "yii2". Issue расширений переезжают в соответствующие проекты.
Политика релизов и версий
- Номера версий будут в формате
2.x.y.z
.2.x
: большие релизы с серьёзными нововведениями. Могут ломать обратную совместмость. Цикл релиза примерно 6 месяцев. На эти релизы пишутся анонсы и обновляется сайт.2.x.y
: небольшие релизы с небольшими нововведениями и исправлениями ошибок. Обратная совместимость с2.x.*
сохраняется. Цикл релизов от 1 до 2 месяцев. На эти релизы также пишутся новости и обновляется сайт.2.x.y.z
: патчи. Только исправления. Обратная совместимость с2.x.*.*
сохраняется. Цикл релизов от 1 до 2 недель. Отдельными новостями не анонсируются, сайт не обновляется (за исключением патчей на тему безопасности). Процесс релиза по большей части автоматический.
- Политика создания веток git:
- Небольшие релизы в ветках
2.x.y
. - Патчи (включая
2.x.y.0
) соответствуют тегу2.x.y.z
в ветке2.x.y
- В ветке "master” ведётся резработка для следующего большого релиза. Как только он готов создаётся ветка
2.x.0
.
- Небольшие релизы в ветках
yii2
, официальные расширения и шаблоны приложений релизятся независимо.- Как
yii2
так и расширения следуют политике версий и веток выше. - Цикл релизов выше применяется только к фреймворку.
- Расширения и шаблоны приложений релизятся как только это понадобится. Расширение не будет обновляться в том случае, если для него не будет исправлений или улучшений.
- Расширения и шаблоны приложений могут иметь отличающиеся от ядра номера версий. К примеру,
yii2-gii
может иметь версию2.0.5
в то время какyii2
будет уже в версии2.1.3
.
- Как
Комментарии RSS по email OK
Предложение поддерживаю! "Мухи отдельно, коклеты отдельно"=)
Если есть возможность назначить ответственных, то думаю можно и разделять. Особенно это важно для issues. Для разработчиков ядра это снизит уровень "шума".
"Расширения и шаблоны приложений релизятся как только это понадобится. " - Отсутствие цикла разработки или какого-то регламента здесь выглядит как непродуманное место. Хотя может так только кажется.
Раньше это было бы неудобно, так как приходилось бы все это качать вручную. А сейчас, как есть Composer - в этом только сплошные плюсы. Еще бы найти быстрый способ качать только необходимые локализации - и вообще идеально будет (а может он уже есть?)
Циклы у расширений будут. Просто они не обязаны будут совпадать с ядром.
Александр, это, случаем, не означает, что каждое расширение будет standalone модулем, т.е. независимо от ядра?
Идеальный сценарий: каждый компонент yii - отдельный модуль. Зная, как тесно связаны компоненты друг с другом, думаю, что не раньше следующего мажорного релиза - издержки архитектуры.
Нет. Без Yii 2, например, Gii работать не сможет. Да и смысла нет.
С Gii всё очевидно - миграции и генератор кода завязаны на фреймворк. Я про, к пример, ODM yii2-mongodb или API для поискового движка yii2-elasticsearch.
"Идеальный сценарий: каждый компонент yii - отдельный модуль" - не гонитесь за разделяемостью и подменяемостью, лучше гонитесь за уменьшением абстракций, сложности и количества классов.
Не очень понял, как будет учтена совместимость отдельных модулей с основной системой? Особенно на уровне больших релизов. Пример (теоретический): вышел большой релиз Yii, в котором, скажем, поменялся компонент или функционал, используемый в gii. При этом изменения для gii не успели внести. В итоге получим новую версию, в которой не работает gii. gii, конечно, не критичный элемент системы, а если это будет тот-же sphinx, redis или smarty? Понятно, что можно подождать изменений или самостоятельно их внести.
Разделение по расширениям - это хорошо, ведь теперь в composer зависимости не придется лить весь фреймворк :)
"При этом изменения для gii не успели внести." - люди ответственные за расширения не на другой планете живут, для них не может быть неожиданного релиза фреймворка, разработчики же общаются между собой. Да и тесты, я уверен, будут запускаться на нескольких стабильных версиях и на мастере фреймворка.
Так что при покрытии тестами проблемы будут известны, и релизеры ядра подождут остальных при необходимости(не на месяц же там работы).
Для этого и существуют версионирование (мажор, минор, патч). Если строго соблюдать этот подход, проблем быть не должно. К примеру, изменилось название метода в ORM yii2-db (где-нибудь в миграциях). Был yii2-db 2.1.0, а стал 2.2.0. Если в конфигурационном файле composer.json для yii2-gii будет прописана версия yii2-db 2.1.*, то совместимость не нарушится.
Ufocoder, так и раньше не приходилось...
На сколько я понял каждая отдельная версия 2.X будет иметь собственную ветку и все изменения для конкретной версии будут вносится в свою ветку 2.X с новым тегом 2.X.Y, а в другие ветки 2.1, 2.2 изменение из 2.0 будет мержится или переносится в ручную как патч?
Да.
Господи, нет.
Код должен выполнять свои задачи тем количеством классов, которым у него все получается. В том числе поддерживать расширяемость и возможности локального исправления ошибок.
Уменьшенная сложность уже была в yii1. В результате один богообъект, плохая автоматизация процессов, мешающие друг другу расширения, километры конфигов и нулевая способность быть изолированно протестированным.
я за
Я новичок, можно задать глупый вопрос, а расширения - это ActiveForm, LinkPager, ArrayHelper и т.д.? Где-нибудь ошибся?
Andrey, нет это встроенные возможности фреймворка. А расширения - это Gii, debug, redis, smarty... Вот список основных: www.yiiframework.com/doc-2.0/guide-structure-extensions.html#core-extensions
Solar, спасибо!
Сделать как в Symfony все равно не получится (
Что именно как в Symfony?
Может, не в том разделе вопрос, но главное, что он к вам Sam. Вы человек авторитетный, многое умеете. Скажите новичку: как правильно читать большой сложный код? Как в нём не запутаться? Для меня вы, разработчики, какие-то просто немыслимые гении. Я уже и правила составлял, мол, "не отвлекайся", "читай построчно", "не пропускай" и т.д. Потом решил читать код от связи к связи, прослеживая путь данных. И всё-равно в какой-то момент начинаю путаться. Пока то, что вы делаете для меня просто чудо. :) Я не против, если и остальные ребята ответят. Всем скажу спасибо. ))
Andrey, а что вы считаете большим и сложным кодом?
В Yii всё хорошо сделано и при должном упорстве можно разобраться. Множество отличных примеров. Спасибо вам за ваш труд. Но когда дело касается javascript... Вот пример кода, который для меня уже достаточно сложен: github.com/blueimp/jQuery-File-Upload/blob/master/js/jquery.fileupload.js Ниточка теряется. ))
Даже не знаю, какой вопрос точнее: "Как это всё охватить" или "с чего начать" или "что и как исключить из поля зрения"...
Наверное, всё дело в сосредоточенности и внимательности. :)
Andrey, для чтения JS стоит прочитать по нему немного материалов перед этим. Например, учебник Кантора.
Спасибо, Сэм.
Привет. А у YII будет аналог laracasts.com с видеоуроками?