Соглашение об именовании релизов

Начиная с Drupal 8 в ядре адаптировали семантическое версионирование.

Начиная с 1 апреля 2020 года — модули и темы оформления получили поддержку семантического версионирования на drupal.org.

Ветки будущих релизов

Вы можете создавать какие угодно ветки с любым именованием для разработки будущего функционала или с другими целями. Здесь нет никаких ограничений.

Если вы назовёте ветку с номером ишьюса в качестве префикса, то ветка будет ассоциироваться в данным ишьюсом: 1234-issue-name-or-other-name.

Тэги релизов и ветки для их разработки

Ветки для разработки

Ветки для разработки должны именоваться по формату {major}.x, либо {major}.{minor}.x, данные версии автоматически получат суффикс -dev.

Таким образом:

  • Ветка 1.x будет создавать релизы 1.x-dev.
  • Ветка 2.1.x будет создавать релизы 2.1.x-dev.

Релиз тэги

Когда вы готовы сделать релиз и зафиксировать свою работу в виде конкретной версии, вы должны создать тэг. Тэги в Drupal должен соответствовать следующему формату {major}.{minor}.{patch} и опциональным префиксом {major}.{minor}.{patch}-(alpha|beta|rc){N} (1.2.3-alpha4).

Эти требования обязательны для создания релизов на drupal.org, остальные именования будут проигнорированы. Также, обратите внимание, в качестве пред-релизных версий можно использовать только alpha, beta и rc с последующим номером без точки в качестве разделителя.

Значения пред-релизных версий

В качестве пред-релизных версий можно использовать только alpha, beta и rc. В Drupal сообществе они имеют следующие трактовки:

  • alpha: Основная часть функционала готова, но имеются серьезные проблемы, включая, уязвимости безопасности. Данный проект мог даже не тестироваться, так что велика вероятность наличия множества неизвестных проблем. У данного релиза уже есть README.txt или README.md в котором описан и документируется проект, включая его API (если оно имеется). API и схема базы данных может быть нестабильна, но их изменения описываются в заметках к релизу, и, при возможности, описываются hook_update_N() для сохранения данных, но никаких других путей для обновления. Не предназначено для использования на рабочих проектах. Целевая аудитория данных релизов — разработчики, кто хочет принять участие в разработке, отладке и тестировании проекта.
  • beta: Все проблемы, которые могут привести к потере данных, а также, проблемы с безопасностью, должны быть решены. Если модуль предоставляет API, оно считается «замороженным» (нельзя изменять до следующего мажорного релиза). Если это имеет место быть, должен быть путь для обновления и предоставлен слой обратной совместимости. Вся документация должна быть актуальной. Целевая аудитория данных релизов — разработчик, желающие принять участие в тестирование, отладке и разработке проекта, а также разработчики, которые используют API проекта для создания своих личных. Не рекомендуется использовать на рабочих сайтах, но допускается, если человек, включающий данный модуль, хорошо знает проект и сможет ликвидировать все возникшие проблемы.
  • rc (release candidate): Кандитат в релизы должен создаваться только если все обнаруженные критически ошибки были исправлены и очередь ишьюсов не имеет нерешенных проблем. Данный тег должен использоваться только тогда, когда разработчик уверен, что данный релиз может быть использован на рабочих сайтах. В Drupal сообществе нет практики, как долго проект может находиться в данном состоянии прежде чем будет создан стабильный релиз, но рекомендуется, продержать на данной версии хотя бы один месяц со статусом «Нужны отзывы». Если в этот период найдена новая проблема, она должна быть исправлена, а также необходимо создать новый кандидат в релизы и желательно повторить ожидание в месяц.

Переход с 8.x-* именования на семантическое

Начиная с Drupal 8, проекты могут быть совместимы сразу с несколькими ядрами Drupal. Таким образом, релизы 8.x-* и семантическое именование используются схожие подходы и вводят путаницу. Например, релиз 8.x-1.0 равен 1.0.0.

Данная возможность доступна всем, но использовать данное именование можно только для новых мажорных релизов. Например, если у вас уже есть модуль 9.x-1.1, то вам нужно создавать новый мажорный релиз 2.0.0, чтобы данные версии начали распознаваться. Соответственно, если у вашего модуля актуальная версия 9.x-3.0, то семантическая версия уже начнётся с 4.0.0.

Смотрите также

Ссылки

🌱 Помогите нам сделать документацию лучше!

Вся документация Druki с отрытым исходным кодом. Нашли ошибку или неточность? Создайте pull request.

Редактировать текущий документ Обсудить улучшение

Или узнайте как контрибутить.

🤔 По-прежнему нужна помощь?

Не нашли ответа на свой вопрос? Попросите помощи у сообщества!

Задайте вопрос на GitHub Смотрите другие ресурсы сообщества