Анонс Joomla 3.4 представил нам новую стратегию релизов, которая заменит концепты Long Term Support (LTS) и Short Term Support (STS), а также соглашение по нумерации ".5". Недавняя публикация по Joomla! Development Strategy, а также FAQ по Joomla's Improved Release Cycle пытаются пролить свет на новую стратегию развития.
Nick A. из команды Joomlapolis провел небольшлой анализ этой стратегии, с переводом которого мы предлагаем ознакомиться ниже. Надеемся, что он поможет вам более четко представить себе направление развития Joomla! CMS.
Как это было раньше
Стратегия разработки / релизов Joomla основывалась на временных циклах релизов и имела следующие характеристики:
- График релизов и нумерация
График релизов включал в себя шестимесячные STS-релизы (3.0, 3.1, 3.2, 3.3), которые спустя шесть месяцев сопровождались LTS-релизом "x.5.0" (например, это должен был быть релиз 3.5.0). Далее этот релиз сопровождался основным "x+1.0.0" релизом (например, 4.0.0). Все LTS-версии помечались как "x.5.0". - Периоды обслуживания (maintainance)
LTS-релизы поддерживались как минимум 27 месяцев, а если быть еще более точным, до шести месяцев после следующего LTS-релиза, в то время как STS-релизы поддерживались в течении одного месяца после следующего STS-релиза. - Совместимость и новые возможности
STS-релизы включали в себя новые обратно совместимые возможности, в то время как LTS-релизы не включали в себя никаких новых возможностей. Основные релизы могли иметь новые возможности, которые не соблюдали обратную совместимость для расширений.
Как это будет в будущем
Новая стратегия будет построена на циклах релизов, которые основываются на новых возможностях и поддерживают Semantic Versioning:
- График релизов и нумерация
Каждый основной релиз "x.0.0" или второстепенный релиз "x.y.0" должен рассматриваться, как в свое время LTS-релиз. Больше никакой "x.5" нумерации. Второстепенные релизы также считаются релизами обслуживания, плюс особое внимание уделяется качеству и обратной совместимости. Релизы больше не основываются на временных рамках ("они готовы, когда они готовы"). - Периоды обслуживания
Каждый основной "x.0.0" релиз отмечает начало X-серии, продолжительность жизни которой ожидается на уровне четырех лет. Каждый второстепенный "x.0.0" релиз, который случится N месяцев спустя после первых двух лет активной разработки основной версии, добавит N месяцев к ожидаемой продолжительности жизни X-серии (делая её 4 года + N месяцев). В теории, продолжительность жизни серии может быть продлена бесконечно, до тех пор, пока будут выпускаться второстепенные релизы. - Совместимость и новые возможности
Второстепенные релизы (например 3.4.0) могут включать в себя новые обратно совместимые возможности. Основные релизы могут включать в себя новые возможности / изменения в API, которые будут обратно несовместимы.
Что эти релизы значат для вас
Вот как выглядит живой пример серии Joomla 3:
- так как Joomla 3.0 была выпущена 27/09/2012, то дата окончания жизни (EOL) для третьей серии была установлена на 27/09/2016 (четыре года после выпуска)
- каждый выход второстепенного релиза Joomla 3.x, который будет сделан после 27/09/2014 (два года активного развития), продлит дату EOL
- так как выход Joomla 3.3 ожидается 30/04/2014, а Joomla 3.4 - 15/07/2014 (обе до 27/09/2014), то они не повлияют на EOL третьей серии
- если предположить, что Joomla 3.5 будет выпущена 01/12/2014, то это автоматически продлит EOL третьей серии до 01/12/2016
Новая стратегия повлияет на новые релизы следующим образом:
- График релизов и нумерация
Понятная [major].[minor].[maintenance] ([основной].[второстепенный].[обслуживание]) семантическая нумерация, без иногда сбивающих "x.5.0" LTS нумераций. Релизы будут выпущены тогда, когда они готовы, без форсирования временных рамок. - Периоды обслуживания
Каждый релиз будет релизом качества и стабильности (и должен рассматриваться, как в свое время LTS-релиз). Каждый новый основной релиз получает ожидаемую продолжительность жизни как минимум в четыре года. - Совместимость и новые возможности
Второстепенные релизы больше заботятся о совместимости и могут включать в себя новые обратно совместимые возможности. Для основных релизов не предполагается существенных изменений, хотя такое возможно. - Разработка и качество
Новая стратегия способствует более гладкой разработке и лучшему качеству кода в плане багов и совместимости. "Они готовы, когда они готовы": никакой спешки в новых возможностях ("не надо беспокоится - если они не попали во второстепенный релиз, то они попадут в следующий") и нехватки времени для закрытия всех багов из-за фиксированной даты релизов (помните Joomla 3.2.0?). Это порождает более гладкий цикл релизов, и избавляет от периода без новых возможностей (один год между последним STS-релизом и новым основным релизом). Это также немного, но все же освобождает основные релизы от ограничений в обратной совместимости.
Выводы и влияние на будущее
Многие статьи обсуждают преимущества и подводные камни каждого из подходов, например:
- How fixed software release dates hurt customers, quality and budgets
- Time-based releases are good for community
- Ubuntu time Based Releases
Мы верим, что Проект Joomla! и его пользователи получат выгоду из нового, более гибкого подхода с более длинными периодами обслуживания, лучшим качеством и совместимостью, более понятной нумерацией версий, продолжающимися инновациями без периода заморозки новых возможностей.
В общем, изменение в стратегии должно развязать сообщество разработчиков, помогая ему в представлении новых инновационных возможностей. Конечно, как со всякой стратегией, не важно, насколько она гибкая и инновационная, конечный результат полностью зависит от участия сообщества в целом.
