Слияние кода завершено, страница обновится автоматически
Существует два возможных способа выпуска JanusGraph:
jar артефакты с помощью кастомной версии Java, которая недоступна в действии GitHub setup-java.Артефакты выпуска будут развернуты в Sonatype OSS с помощью плагина Maven Deploy. У вас должно быть зарегистрированное имя пользователя Sonatype, связанное с организацией JanusGraph. Подробнее см. здесь.
[DISCUSS] на janusgraph-dev с предложениями того, что должно войти в выпуск и целевой даты[VOTE] на janusgraph-dev и получите необходимое количество голосов от трех членов TSC
Пропустите всю эту секцию, если вы используете автоматический поток выпуска. Процесс выпуска был протестирован только на Linux и macOS. Необходимо установить следующие инструменты.
Артефакты JanusGraph подписываются с помощью цифровой подписи GPG.
Если у вас нет ключа подписи GPG, включённого в файл KEYS, вам потребуется создать его и обновить файл KEYS.
Если ваш ключ уже включен в файл KEYS, пропустите этот шаг.
Перейдите на страницу релизов и скачайте файл KEYS (расположенный в разделе Assets) последнего релиза.
Сгенерируйте свой ключ:
gpg --full-generate-key
Выберите:
CODE SIGNING KEY
Добавьте свой ключ в файл KEYS:
(gpg --list-sigs <key id> && gpg --armor --export <key id>) >> KEYS
После создания ключа и добавления его в файл KEYS он должен быть опубликован на публичном сервере ключей.
Вы можете загрузить ключ на несколько серверов в пуле или использовать альтернативный сервер, если pgp.mit.edu недоступен.
Конфигурация Sonatype обычно включает следующие серверы ключей: keyserver.ubuntu.com, keys.openpgp.org, pgp.mit.edu.
gpg --keyserver <key server> --send-keys <key id>
```Пример:
```shell
gpg --keyserver pgp.mit.edu --send-keys 7F87F9BD4D9F71A6
Артефакты выпуска будут загружены в временную директорию на Sonatype OSS. Если вы не настроите Maven с паролями сервера, плагин Maven Deploy столкнётся с ошибкой 401 Unauthorized. Шаги ниже взяты из этого руководства.
mvn --encrypt-master-password
$HOME/.m2/settings-security.xml
<settingsSecurity>
<master>{основной пароль}</master>
</settingsSecurity>
Обратите внимание: Пароль и окружающие фигурные скобки {} должны быть помещены в тег <master>. Пример: <master>{1234567ABCDEFG}</master>
$HOME/.m2/settings-security.xml, зашифруйте пароль сервера: mvn --encrypt-password
$HOME/.m2/settings.xml используя ваш логин Sonatype и зашифрованный пароль сервера```xmlВы можете передать его как параметр командной строки Maven с помощью -Dgpg.passphrase=$GPG_PASS.
Вы также можете зашифровать ключ GPG с помощью mvn --encrypt-password и добавить его в файл $HOME/.m2/settings.xml, как показано ниже.
Может потребоваться один раз ввести ваш пароль GPG.
Иначе вам придётся многократно вводить свой пароль GPG при каждом запросе во время сборки.```xml
ossrh
{sonatype username}
{encrypted sonatype password}
gpg
<gpg.executable>gpg</gpg.executable>
<gpg.passphrase>{encrypted gpg passphrase}</gpg.passphrase>
gpg
# Шаги выпуска
### Создание темы обсуждения
Рекомендуется использовать предыдущие выпуски в качестве шаблона.
Вот [ссылка](https://groups.google.com/d/msg/janusgraph-dev/BGaCCH1cTCE/gR8OGm32AQAJ) на тему обсуждения для выпуска 0.2.1.
Важно выделить, какие незаконченные работы должны войти в текущий выпуск и назначить менеджера выпуска.
### Очистка меток выпусков
Пройдитесь по всем коммитам, добавленным с момента последнего выпуска, и убедитесь, что они правильно помечены текущим выпуском.
Любые закрытые задачи в результате этих коммитов также должны быть отмечены как часть текущего выпуска.
### Завершение всех незаконченных работ
Перед отправкой pull request с обновленными номерами версий убедитесь, что все задачи в [milestone выпуска](https://github.com/JanusGraph/janusgraph/milestones) завершены.
Любые незаконченные pull request, которые будут требовать переадресации на будущие milestones.
### Создание pull request с обновлением версий
До того как можно будет создать артефакты и провести голосование, номер версии следует обновить в файлах `pom.xml`.
Убедитесь, что последняя поддерживаемая версия в файле `.github/workflows/docker-release.yml` корректна.#### Обновление справочной документации конфигурации
```Shell
mvn --quiet clean install -DskipTests=true -pl janusgraph-doc -am
Эта команда удалит SNAPSHOT из всех версий в файлах pom.
mvn versions:set -DremoveSnapshot=true -DgenerateBackupPoms=false
После установки версии обновите тэг SCM, открыв основной файл pom.xml и заменив <tag>HEAD</tag> на тэг выпуска.
Пример: <tag>v0.3.2</tag>
Обновите файлы, зависящие от версии, в корне и источниках документации в подпапке docs:
docs/changelog.md — Добавьте / завершите раздел выпускаmkdocs.yml — Обновите latest_version и проверьте все остальные пакетные версии..github/workflows/docker-release-tags.yml — если вы публикуете последнюю младшую версию основной версии, вам также следует обновить LATEST_RELEASE в этом файле (игнорируя версию патча). Это временное решение до автоматизации процесса (см. задача #3905).Вы можете также потребуется обновить следующие файлы в основном репозитории для любых новых или обновленных зависимостей:
NOTICE.txtСоздайте коммит выпуска:
git commit -m "JanusGraph release <версия> [cql-tests] [tp-tests]" -s
Рекомендуется добавить [tp-tests] в сообщение коммита, чтобы запустить тестовый набор TinkerPop.
После одобрения и слияния обновлений продолжите процесс выпуска.### Отправка тега, связанного с версией
Создайте тег выпуска с помощью следующей команды:
git tag -a <тег выпуска> -m ""
Тег выпуска должен соответствовать следующему шаблону: v.[major].[minor].[patch]. Пример:
git tag -a v0.3.2 -m ""
Отправьте тег на удаленный репозиторий JanusGraph (обычно upstream):
git push upstream <тег выпуска>
В случае изменения выпуска после отправки тега вам потребуется удалить его, связать с новым коммитом и снова отправить. После этого продолжите выполнение следующего шага:
git tag --delete <тег выпуска>
git push upstream :<тег выпуска>
git tag -a <тег выпуска> -m ""
git push upstream <тег выпуска>
Если вы используете автоматический поток выпуска пропустите этот раздел.
git fetch
git pull
git stash save
git clean -fdx
clean между первой и второй командами.mvn clean install -Pjanusgraph-release -DskipTests=true
mvn deploy -Pjanusgraph-release -DskipTests=true
```* Установите MkDocs, если он ещё не установлен. Он необходим для сборки документации.
1. Установите `python3` и `pip3` (наиболее новую версию pip)
* Также можно проверить руководство по установке [material-mkdocs](https://squidfunk.github.io/mkdocs-material/getting-started/)
2. Установите зависимости с помощью `pip3 install -r requirements.txt`
* Подготовьте файлы для выпуска на GitHub
```Shell
export JG_VER="janusgraph-0.5.0"
export JG_FULL_VER="janusgraph-full-0.5.0"
mkdir -p ~/jg-staging
cp janusgraph-dist/target/${JG_VER}.zip* ~/jg-staging/
cp janusgraph-dist/target/${JG_FULL_VER}.zip* ~/jg-staging/
mkdocs build
mv site ${JG_VER}-doc
zip -r ${JG_VER}-doc.zip ${JG_VER}-doc
gpg --armor --detach-sign ${JG_VER}-doc.zip
cp ${JG_VER}-doc.zip* ~/jg-staging/
Если это завершается ошибкой "Inappropriate ioctl for device", выполните:
export GPG_TTY=$(tty)
cd ~/jg-staging
gpg --verify ${JG_VER}.zip.asc ${JG_VER}.zip
gpg --verify ${JG_FULL_VER}.zip.asc ${JG_FULL_VER}.zip
gpg --verify ${JG_VER}-doc.zip.asc ${JG_VER}-doc.zip
Если вы используете автоматическую последовательность выпусков, ваш черновик релиза будет создан автоматически,
и он будет заполнен всеми необходимыми артефактами релиза. Обратите внимание, вам потребуется подождать завершения действия ci-publish.yml
после того как вы отправите тег (обычно это занимает около 10–15 минут до завершения этого CI) для создания черновика релиза.
Вам потребуется изменить текстовое содержание черновика релиза и заменить *MILESTONE_NUMBER* правильным номером майлстоуна,
связанным с этим релизом. Вам также потребуется добавить "Замечательные новые возможности", "Проверенная совместимость",
"Установленные версии в Предварительно Упакованной Распределении" и "Контрибьюторы" в текстовое содержание релиза.
Используйте предыдущие релизы в качестве шаблона. Версии можно скопировать из журнала изменений.
Вам потребуется самостоятельно определить и отметить новых участников проекта. Рекомендуется сохранять выпуск в статусе черновика до тех пор, пока вы полностью не готовы начать голосование.Обратите внимание, если ваш выпуск уже создан из-за повторной отправки тэга, то содержание вашего выпуска не будет изменено.
Изменятся только связанные с ним артефакты. Вам также потребуется удалить предыдущий Sonatype стейджинговый выпуск.
При входе в систему GitHub перейдите на страницу выпусков JanusGraph и нажмите кнопку Создать новый выпуск.
Укажите номер тэга, целевую ветвь и заголовок.
Для описания используйте предыдущие выпуски как шаблон и обновите проверенные версии соответственно.
Все артефакты, созданные и перемещённые в ~/jg-staging/ в предыдущем шаге, должны быть добавлены в черновик выпуска.
Не забудьте отметить его как предварительный выпуск.
Рекомендуется сохранять выпуск в статусе черновика до тех пор, пока вы полностью не готовы начать голосование.
Кроме артефактов в ~/jg-staging/, файл KEYS также должен быть добавлен в выпуск.
Войдите на Sonatype и выберите разделы Стейджинговых репозиториев под Управлением сборками. Если вы недавно загрузили, вы легко найдёте свой стейджинговый выпуск, выполнив сортировку по убыванию. Убедитесь, что содержимое полное, затем проверьте выпуск перед тем, как закрыть его.Этот шаг выполнит проверку всех артефактов. В частности, это проверит наличие действительной подписи GPG для всех артефактов. Если этот шаг завершится ошибкой, вам потребуются изменения перед началом голосования.
[VOTE] темуКак только все артефакты будут загружены на страницу выпусков GitHub и стейджинговый репозиторий будет заполнен и закрыт, пришло время создать тему [VOTE].
Вот пример темы голосования для JanusGraph 0.3.1, которую можно использовать как шаблон.
Подобно политике голосования Apache для выпуска требуется согласие трёх членов TSC для прохождения голосования.
См. документацию по политике выпуска JanusGraph для получения более подробной информации.
После выпуска артефактов в Maven Central и отправки истории в публичный репозиторий GitHub, выпуск больше не может быть отменён.
Войдите в Sonatype и выберите закрытый ранее стейджинговый репозиторий.
После выбора выпуска нажмите кнопку Опубликовать.
Стейджинговая директория должна быть автоматически удалена после завершения выпуска.
Артефакты выпуска будут синхронизированы с Maven Central примерно через два часа.### Создайте новую ветвь при необходимости
Если выпуск происходил в ветви master (которая используется для последней минорной или основной версии), вам потребуется создать новую ветвь в формате v${major_version}.${minor_version} (патч версия игнорируется). Также, если это новый основной выпуск, убедитесь, что ветвь защищена, перейдя на страницу правил защиты ветвей
и создав те же правила защиты, что были использованы для ветви master. Этот шаг необходим для того, чтобы следующий коммит (коммит восстановления сборки) запускал процесс сборки документации и новое имя ветви было добавлено в выпадающем меню документации как последний выпуск.
mvn versions:set -DnewVersion=0.3.0-SNAPSHOT -DgenerateBackupPoms=false
Восстановите <scm> до <tag>HEAD</tag> в корневом файле pom.xml.
Также обновите snapshot_version в файле mkdocs.yml.
Если вы создали новую ветвь, убедитесь, что также обновили targetBranchChoices в файле .backportrc.json и labels в файле .github/dependabot.yml.
Эти изменения могут быть отправлены одним коммитом.
Редактируйте выпуск на GitHub и снимите флажок для промежуточного выпуска. Убедитесь, что на странице выпуска он теперь помечен как "Окончательный выпуск".
Вот пример объявления о выпуске. После объявления выпуска на наших рассылках также объяви о нем в Twitter и Discord. Прошлые объявления также можно использовать как вдохновение. Убедитесь, что вы опубликовали пост в канале объявлений Discord. Это позволит другим серверам Discord получать наши объявления.
Если вы найдете что-либо неправильным или незавершенным в этом документе во время подготовки выпуска, важно вернуть эту информацию сообществу. Детали должны быть добавлены в этот документ, а высокие уровни могут потребовать обновлений в политике выпуска.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )