Публикация проекта и создание релизов на Drupal.org

Всем привет! На выходных в очередной раз мой альтруизм вынудил меня потрудится на благо Drupal.org, и я наконец-то сделал релиз двух своих модулей. Собственно этот пост написан с целью похвастаться, ну и также рассказать, как делаются релизы проектов.

Если вы внимательно следили за вещанием моего блога, то должны помнить, что сначала был пост о том, как создаются Sandbox проекты на Drupal.org, за ним следовала инструкция получения статуса разработчика и права создания Full Project. Вот сейчас я, собственно, и закончу эту трилогию постом о том, как же перевести проект из песочницы в полноценную версию.

После прохождения проверки на говнокод на странице редактирования вашего проекта должна появиться вкладка «Promote», по нажатию на которую вам будет предложено выбрать короткое имя для проекта, а также выведено уведомление о том, что «обратного пути уже не будет». Если вы четко решили, что готовы поддерживать проект, отвечать на тикеты и уделять свое свободное время Drupal.org – тогда добро пожаловать во взрослый мир!

Создание релизов проекта

Проект опубликован. Однако не спешите об этом трубить во всеуслышание – есть еще несколько моментов, которые необходимо завершить. Первым делом обратите внимание на то, что после публикации модуля URL вашего репозитория был изменен, поэтому его придется склонировать заново к себе на рабочую машину.

Далее вы должны заметить, что внизу страницы отсутствуют привычные ссылки для скачивания архивов с файлами модуля. А все потому, что у нашего проекта пока еще отсутствуют релизы. Переходим на страницу редактирования проекта, жмем по вкладке «Releases» и, полагаясь на логику и интуицию, следуем шаг за шагом к форме, изображенной на скриншоте.

Боюсь вас ввести в заблуждение, но таким образом, насколько я понял, мы создаем релиз ветки 7.x-1.x и предоставляем пользователям возможность скачивать DEV-версию модуля, которая состоит из слепка текущего состояния ветки.

Еще хочу сказать, что после создания релиза ветки необходимо подождать порядка 5 минут, пока будет создан архив. Поэтому не паникуйте, что нода вашего релиза выглядит неопубликованной – терпение, только терпение.

Добавление тэгов

Далее необходимо предоставить пользователям стабильный «зелененький» релиз. Если вы попробуете нажать «Add new release» на странице релизов, то получите сообщение о том, что не найдено валидных веток или тэгов («No valid branches or tags found») для создания релиза. С ветками мы уже разобрались, осталось внести ясность в тэгирование.

Добавлять тэг к коммиту – это стандартная операция Git, однако ей пользуются, как показывает моя практика, редко. Добавляется тег следующим образом:

git checkout  7.x-1.x
git tag 7.x-1.0
git push origin tag 7.x-1.0

Эта информации в принципе есть на справочной вкладке вашего проекта «Version control». Вы вольны в выборе имен для тэгов до тех пор, пока не захотите закрепить за определенным тегом релиз вашего проекта. Чтобы на Drupal.org вас не сочли варваром, ознакомьтесь с конвенцией Release naming conventions. О том, чем отличаются Alpha, Beta и RC версии вы также можете прочитать по указанной ссылке.

В случае c модулем Views scroll pager для первого релиза я решил сделать метку «7.x-1.0-rc1». После добавления тэга у вас должна появиться возможность создать еще один релиз, который будет привязан к конкретному слепку коду в отличие от dev-версии. После публикации релиза на странице вкладки «Releases» выбираем «Recommended major version» и получаем стабильную версию модуля, доступную для скачивания. Ура!

На этом праздник не заканчивается, так как сегодняшним постом я смело могу закрывать одну из своих целей, поставленных в самом начале создания блога! Вроде и мелочь, а приятно, что я хоть чего-то да добился xD