Distributor: Выпуск версии 1.6.0

Эта проблема предназначена для отслеживания изменений в выпуске 1.6.0. Целевая дата выпуска: подлежит уточнению .

Предварительные шаги

• [] просматривать и (объединять или отбрасывать) открытые PR в вехе

Шаги выпуска

• [x] Ветвь: Начиная с develop , вырежьте ветку выпуска с именем release/1.6.0 для ваших изменений.
• [x] Повышение версии: выделите номер версии в distributor.php , distributor.pot и readme.txt если он еще не соответствует выпускаемой версии. В distributor.php обновите свойство плагина «Версия:» и константу плагина DT_VERSION , убедившись, что оно имеет суффикс -dev .
• [x] Список изменений: Добавить / обновить журнал изменений в CHANGELOG.md .
• [x] Реквизиты: обновите файл CREDITS.md любыми новыми участниками, подтвердите правильность сопровождающих.
• [x] Обновления Readme: при необходимости внесите любые другие изменения в readme. README.md ориентирован на GitHub, а readme.txt содержит контент, специфичный для WordPress.org. Эти два немного отличаются.
• [x] Переводы: обновите файл .pot , запустив npm run makepot .
• [x] Слияние: выполните слияние без перемотки вперед из ветки выпуска в develop (или объедините запрос на перенос), затем сделайте то же самое для develop в master ( git checkout master && git merge --no-ff develop ). master содержит стабильную разрабатываемую версию.
• [x] Сборка: в ветви master запустите npm install && npm run release . Это создаст подпапку с именем release с клонированной веткой stable в качестве рабочего дерева и копированием последних изменений. Убедитесь, что все новые файлы находятся в папке release ; в противном случае вам может потребоваться добавить их в gulp-tasks/copy.js .
• [x] Проверка: есть ли какие-нибудь измененные файлы в master ? Если это так, вернитесь к develop , запустите все необходимые задачи и зафиксируйте эти изменения, прежде чем вернуться к шагу 6.
• [x] Тест: переключитесь на работающий распространитель из версии в подпапке release и выполните несколько общих задач в пользовательском интерфейсе, чтобы убедиться в функциональности.
• [x] Push: Первый мастер: git push , затем из каталога release добавьте все файлы и отправьте их в origin stable : git push origin stable .
• [x] Выпуск: создайте новый выпуск , присвоив тегу и выпуску новый номер версии и выбрав ветку stable . Вставьте список изменений из CHANGELOG.md в текст релиза и включите ссылку на закрытые проблемы на этапе 1.6.0 . Теперь выпуск должен отображаться в разделе выпуски .
• [] Удар версии (снова): в ветви develop ( cd ../ && git checkout develop ) увеличьте номер версии в distributor.php , distributor.pot и readme.txt в 1.6.1-dev . Ничего страшного, если следующий выпуск может иметь другой номер версии; это изменение можно обработать прямо перед выпуском на первом этапе, как это может быть и с аннотациями @since .
• [x] Завершение этапа: отредактируйте этап 1.6.0, указав дату выпуска (в поле Due date (optional) ) и ссылку на выпуск GitHub (в поле Description field ), затем закройте этап.
• [x] Отбросить незавершенные элементы: если какие-либо открытые проблемы или PR, которые были достигнуты в течение 1.6.0 , не попадают в выпуск, обновите их веху до 2.0.0 или Future Release .

Пост-релизные шаги

• [] отправить Дистрибьютора в Packagist (см. №356)