Вы здесь

Цикл выпуска версий

Каждая версия проходит через следующие четыре периода разработки.

1. Разморозка кода (code thaw)
После выхода предыдущей версии Друпала, Drupal HEAD открывается для добавления новых возможностей. Мы называем этот период разморозкой кода. В этой периоде, название игры — мировое доминирование. Всё разрешено. Исправление ошибок, переписывание Form API, перенос полезных дополнительных модулей в ядро, удаление ненужных модулей из ядра, изменение API ядра, добавление и удаление шаблонов, в общем всё, о чём вы мечтаете. Капля всегда движется и размороженный код, это шанс сделать реальностью все свои дикие мечты. Когда разморозка заканчивается, мы получаем состояние заморозки кода (code freeze) и после этого начинаем скрупулёзно обрабатывать принятые патчи.
2. Скрепление кода (code slush)
Этот период добавлен в Друпал 7, так как Друпал 7 имел такой нетипично долгий период с размороженным кодом. В этом периоде, который имеет точные временные рамки, разработчики ядра определяют важные возможности, которые уже завершены и(или) очень важны для будущего проекта и делают необходимые изменения для этого набора (и только его).

Это период «последней минуты» для изменения API и добавления связанных с существующими возможностей, которые уже реализованы в процессе разморозки кода. Никаких других новых возможностей. Никаких других изменений в API или дополнений.

В конце этой фазы, мы объявляем о заморозке API и больше никакие изменения в API не разрешены (за исключением исправления критических ошибок, которые могут обнаружиться позднее и блокируют выход стабильной версии). Изменения API включают изменение подписей функций, добавление или удаление хуков, добавление или исключение файлов шаблонов или переменных шаблонов и что-либо ещё, что очень важно сделать до выхода финальной версии.

3. Полировка кода (polish phase)
Теперь наступает время для вещей, которые не получили внимания, когда все с сумасшествием ломали Друпал и набивали его новыми возможностями. Здесь мы работаем над оптимизацией быстродействия, эргономики, документированием и изменением строк интерфейса. Это отличное время чтобы убедиться, что справочные страницы Друпала содержат корректную информацию или почистить разметку кода.

В конце этого периода, мы объявляем о заморозке строк и интерфейса. Также как и с заморозкой API, это означает, что мы больше не изменяем строки интерфейса или другие аспекты интерфейса (за исключением критических ошибок, которые могут обнаружиться позднее блокируют выход стабильной версии).

4. Публикация версий (release phase)
Наконец, наступает период публикации версий. В этом периоде выпускаются альфа, бета, RC-версии и стабильная версия системы.

В этой фазе усилия сосредоточены на исправлении критических ошибок и доведении их количества до нуля. После того, как количество критических ошибок будет доведено до нуля (или близко к нему), выходит RC-версия. После того, как все критические ошибки в RC-версиях будут исправлены и не будут появляться новые критические ошибки, будет выпущена финальная версия системы. Всё шумят, хлопают друг дружку по спине и потом мы снова переходим к разморозке кода.

Все эти периоды легко показать в виде воронки:

Drupal. Цикл выпуска версий

Здесь мы видим, что каждый период цикла получает всё меньшее и меньшее количество типов патчей и все изменения всё больше замыкаются на разработчиков ядра.

  • В процессе разморозки кода, патчам API уделяется больше внимания, чем шлифовке кода и тексту интерфейса
  • В процессе полировки, патчи шлифующие код и текст интерфейса получают полное внимание, а патчи изменяющие API не применяются
  • В процессе публикации версий, мы концентрируем всё внимание на критических ошибках и других ошибках, которые нужно исправить до выхода стабильной версии. Патчи, которые делают полировку или исправляют некритические ошибки API переносятся в следующую основную версию системы и следующий цикл разморозки кода

Что такое изменение API

В общем смысле, изменение API означает всё, что затрагивает разработчиков модулей, тем или что-то, что связано с написанием документации к новой версии Друпала и что потребует её серьёзного переписывания. Изменение подписей функций или хуков; добавление и удаление функций и хуков; добавление, удаление и изменение функций тем; добавление, удаление и изменение файлов шаблонов или переменных шаблонов и так далее.

Как только объявляется заморозка кода, мы вносим только такие изменения в API, которые исправляют критические ошибки. Если есть способ исправить ошибку уровня «major» или «normal» без изменения API, мы идём на это, так же, как мы делаем это в стабильных версиях.

Что такое критическая ошибка

Критическая ошибка это что-то такое, что нарушает работу Друпала так сильно, что это затрагивает так много пользователей, что мы не можем использовать текущую версию без исправления этой ошибки. Посмотрите статью о приоритете уровней в сообщениях.

В общем виде, критические ошибки это:

  • Ошибки связанные с обновлением
  • Ошибки вызывающие потерю данных
  • Ошибки создающие угрозу безопасности
  • Ошибки, которые не дают закончить тест тест-ботам
  • Нарушение поведения чего-либо, что работало в предыдущей версии

Окончательно, что является критическим, а что нет, решают разработчики ядра.
Здесь ещё можно привести очень длинный список вещей, которые не являются критическими:

  • Неприятные проблемы, которые так же существуют и в предыдущих версиях. Если они не настолько плохи, чтобы блокировать выход предыдущих версий Друпала, то они не будут блокировать и выход следующих
  • Крайние случаи, которые несмотря на свою ужасность, затрагивают небольшое количество пользователей
  • DX-проблемы, которые не мешают использованию Друпала
  • UX-проблемы, которые не мешают использованию Друпала
  • TX-проблемы, которые не мешают использованию Друпала

What's the harm in letting in API changes late?

There are consequences every time we deviate from the overall release plan:

  • Takes time and focus away from critical, release-blocking issues: Since none of us are being paid to work on Drupal core, we need to allocate our attention and focus in the most efficient way. That generally means focusing on critical, release-blocking bugs first, everything else second.
  • Sends a signal to all other core contributors that we're still in "polish" phase: All of us have our own pet niggles with Drupal that we really wish were better than we were. Tweaking a theme function here. Adding a hook there. If the core maintainers send up the signal that these sorts of patches are still on the table, suddenly everyone wants to jump in and add their own pet project, too. Which means critical issues aren't being looked at, and core maintainers need to divide their attention.
  • Creates morale issues and dissent: The flip side of the above. When people perceive favouritism or special treatment (contributor X's "polish phase" patches are getting committed during release phase while contributor Y's were bumped to Drupal 8), it builds resentment and mistrust. It also builds this feeling when the vast majority of the team is working hard on the "core" issues leading directly to release, but there are other people off in the sidelines scratching their own itches.
  • Makes the release cycle even longer: Each one of these patches are not something that happens for free. Each patch that goes into core needs to be read, evaluated, reviewed, tested, tweaked, tested again, given final look-over by a core maintainer, and finally committed. This is all time not being spent on the "core" issues that get the release out the door. Additionally, every time code changes, it opens up the possibility for follow-up issues, or at the very least re-rolls in other patches to fix tests or whatnot.
  • Eliminates incentive to join with community at appropriate times: If we don't ever end code thaw, and we don't ever end polish phase, what on earth is the incentive for helping out during those times when we as a community really need people to rally? If we are changing APIs and the theme system months after we declared an API/markup freeze, what's the incentive for porting modules and themes during code freeze? Much safer to wait until the next version actually ships, which inevitably leads to a major core release with 0 contributed module support, which isn't good for anyone.

Will one little patch like this end the world? No, of course not. But it's death by a thousand cuts. So core maintainers and major core contributors tend to give more and more pushback the later in the cycle major changes are introduced.