Версионирование Yii

Этот документ описывает политику версионирования Yii. Текущая стратегия - вариант Semantic Versioning.

Внутри core team мы неоднократно подчёркивали важность обратной совместимости в релизах 2.0.x. Но это идеальный план. На практике добиться этого сложно. Подробнее в документе Обратная совместимость.

Коротко, политика версионирования Yii 2:

Номера версий

Номера версий имеют формат 2.x.y.z, где z опускается, если равен 0.

Возможная версия Yii 3 здесь не рассматривается, т.к. ожидается переход аналогичный 2.0 после 1.0. Такое происходит раз в 3-5 лет, в зависимости от развития внешних технологий (например, переход PHP с 5.0 на 5.4).

2.X.0: мажорные релизы

Релизы с нарушением обратной совместимости. Содержат крупные функции и изменения, которые могут сломать BC. Обновление с предыдущих версий может быть нетривиальным, но полное руководство по обновлению предоставляется.

• Основное содержание - новые функции и исправления багов
• Включают минорные функции и баг-фиксы из патч-релизов
• Могут содержать BC-ломающие изменения, записанные в UPGRADE-2.X.md
• Цикл релиза - около 12 месяцев и более
• Требуют пре-релизы: 2.X.0-alpha, 2.X.0-beta, 2.X.0-rc
• Требуют новостных публикаций и маркетинговых усилий

2.x.Y: минорные релизы

Минорные релизы, в основном совместимые с предыдущими версиями. В идеале содержат только изменения, не затрагивающие обратную совместимость. Но не всегда получается сохранить 100% BC, поэтому заметки об обновлении записываются в UPGRADE.md. На практике, поскольку 2.0.x выходят чаще, мы добавляем в них и минорные функции, чтобы пользователи могли использовать их раньше.

• Основное содержание - исправления багов и улучшения
• Должны быть в основном обратно совместимы для безболезненного обновления. Допускается несколько исключений, задокументированных в UPGRADE.md
• Цикл релиза - 1-2 месяца
• Пре-релизы (alpha, beta, RC) не требуются
• Должны постоянно сливаться обратно в master (минимум раз в неделю вручную)
• Сопровождаются новостными публикациями. Сайт проекта обновляется

2.x.y.Z: патч-релизы

Патч-релизы, которые должны быть на 100% обратно совместимы. Содержат только исправления багов. Новостные публикации и обновление сайта не требуются (если нет крупных/security исправлений). Процесс релиза в основном автоматизирован.

• Содержат только исправления багов, без новых функций
• Должны быть на 100% обратно совместимы. Единственное исключение - security-проблемы, которые могут потребовать нарушения BC
• Цикл релиза - 1-2 недели
• Пре-релизы (alpha, beta, RC) не требуются
• Должны сливаться обратно в master при релизе

Политика ветвления

• Ветка master - ветка разработки текущего стабильного мажорного релиза, сейчас версии 2.0.x.
• Каждый новый мажорный релиз разрабатывается в ветке с именем версии, например 2.1.
• Когда новый мажорный релиз 2.n готов, из master создаётся ветка поддержки 2.(n-1).x. Т.е. ветка 2.0 создаётся когда версия 2.1.0 выпускается как стабильная и далее разрабатывается в master (ср. схема именования веток composer).
• Для патч-релизов создаются теги 2.x.y.z и ветка 2.x.y. Для релизов 2.x.y.0 ноль опускается.
• Изменения из веток поддержки 2.n.x постоянно сливаются обратно в master.

Схема ветвления на примере истории коммитов:

Релизы

Фреймворк и официальные расширения релизятся независимо друг от друга, т.е. расхождение номеров версий между фреймворком и расширением - ожидаемая ситуация. Шаблоны приложений всегда релизятся вместе с фреймворком.

Циклы релиза, описанные выше, относятся только к ядру фреймворка. Расширения релизятся по мере необходимости. Расширение может долго не получать новых релизов, если в нём нет исправлений или улучшений.