Контрольный список для выпуска:

Требования:

— [ ] Аккаунт на GitHub с доступом к solidity (https://github.com/ethereum/solidity), solc-js (https://github.com/ethereum/solc-js), solc-bin (https://github.com/ethereum/solc-bin), solidity-website (https://github.com/ethereum/solidity-website).
— [ ] Аккаунт в DockerHub с правами на отправку в образ solc (https://hub.docker.com/r/ethereum/solc).
— [ ] Аккаунт Launchpad (Ubuntu One) с членством в команде «Ethereum» (https://launchpad.net/~ethereum) и ключом gnupg для электронной почты в домене ethereum.org (должен быть версии 1, gpg2 не подойдёт).
— [ ] Зависимости PPA-скриптов Ubuntu/Debian: devscripts, debhelper, dput, git, wget, ca-certificates.
— [ ] Добавленный аккаунт npm Registry (https://www.npmjs.com) в качестве соавтора пакета solc (https://www.npmjs.com/package/solc).
— [ ] Доступ к аккаунту solidity_lang в Twitter (https://twitter.com/solidity_lang).
— [ ] Аккаунт Reddit (https://www.reddit.com), которому как минимум 10 дней, с минимум 20 кармой комментариев (/r/ethereum требования).

Предполётные проверки:

За день до релиза или раньше:
— [ ] Запустить make linkcheck из docs/ и исправить любые неработающие ссылки, которые он найдёт. Игнорировать ложные срабатывания, вызванные якорями href и фиктивными ссылками, которые не должны работать. Примечание: чтобы запустить проверку ссылок, убедитесь, что вы сначала собрали документы через docs.sh.
— [ ] Ещё раз проверить, что последние сборки документов на readthedocs (https://readthedocs.org/projects/solidity/builds/) прошли успешно.
— [ ] Убедиться, что все объединённые PR, которые должны иметь записи в журнале изменений, действительно имеют их.
— [ ] Перезапустить CI на верхних коммитах основных веток во всех репозиториях, которые не имеют ежедневной активности, создав тестовую ветку или PR:
— [ ] solc-js.
— [ ] solc-bin (убедитесь, что проверка сравнения байт-кода прошла).
— [ ] (Необязательно) Создать предварительный выпуск в нашем Ubuntu PPA, следуя шагам в разделе PPA ниже на develop, а не на теге. Это рекомендуется особенно при работе с PPA впервые, когда мы добавляем новую версию Ubuntu или когда скрипты PPA были изменены в этом цикле выпуска.
— [ ] Проверить, работает ли релиз-архив solc-js. Поднимите версию локально, добавьте soljson.js из CI, соберите его, сравните структуру файла с предыдущей версией, установите его локально и попробуйте использовать.
— [ ] Просмотрите «Уроки прошлых выпусков» (https://notes.ethereum.org/@solidity/release-mistakes), чтобы убедиться, что вы не повторяете тех же ошибок.

Черновики:

За день до выпуска или раньше:
— [ ] Создать черновик PR для сортировки журнала изменений.
— [ ] Создать черновые PR для повышения версии в solidity и solc-js. Примечание: PR solc-js пока не пройдёт проверки CI, поскольку зависит от двоичного файла soljson из solc-bin.
— [ ] Создайте черновик релиза на github.
— [ ] Создайте черновой PR для обновления soliditylang.org.
— [ ] Создайте черновики сообщений в блоге.
— [ ] Подготовьте черновики объявлений в Twitter, Reddit и Solidity Forum.

Сообщение в блоге:

— [ ] Напишите сообщение на solidity-website (https://github.com/ethereum/solidity-website/tree/main/src/posts) в категории «Releases» и объясните некоторые новые функции или концепции.
— [ ] Если есть важные ошибки, напишите сообщение на solidity-website (https://github.com/ethereum/solidity-website/tree/main/src/posts) в категорию «Security Alerts».
— [ ] Получите одобрение постов до начала релиза.

Журнал изменений:

— [ ] Отсортируйте записи журнала изменений по алфавиту и исправьте любые замеченные ошибки. Зафиксируйте это.
— [ ] Обновите журнал изменений, включив дату выпуска.
— [ ] Запустите scripts/update_bugs_by_version.py, чтобы заново создать bugs_by_version.json из changelog и bugs.json. Убедитесь, что полученный bugs_by_version.json имеет новую пустую запись для новой версии.
— [ ] Внесите изменения, создайте запрос на вытягивание и дождитесь тестов. Затем объедините его.
— [ ] Скопируйте журнал изменений в... релиз блог пост.

Create the Release

• Создайте релиз на GitHub. Установите целевую ветку в «develop» и тег для новой версии, например, «v0.8.5». Включите следующее предупреждение: «Релиз всё ещё находится в разработке. Вы можете увидеть неработающие ссылки, а двоичные файлы могут быть недоступны из всех источников.». Не публикуйте его пока — нажмите кнопку «Сохранить черновик» вместо этого.
• Поблагодарите добровольных участников в примечаниях к релизу на GitHub. Используйте «scripts/list_contributors.sh v<предыдущая версия>», чтобы получить первоначальный список имён. Удалите разные варианты одного и того же имени вручную перед использованием вывода.
• Проверьте, что все тесты на последнем коммите в «develop» зелёные.
• Нажмите кнопку «Опубликовать релиз» на странице релиза, создав тег. Важно: не должно выполняться до слияния всех PR, включая очистку журнала изменений и дату.
• Дождитесь выполнения CI на самом теге.

Upload Release Artifacts and Publish Binaries

• Переключитесь на тег, для которого должны быть созданы архивы.
• Создайте файл «prerelease.txt»: («echo -n > prerelease.txt»).
• Запустите «scripts/create_source_tarball.sh», находясь на теге, чтобы создать исходный архив tar. Это создаст архив в каталоге с именем «upload».
• Возьмите архив tar из каталога «upload» (его имя должно быть «solidity_x.x.x.tar.gz», иначе «prerelease.txt» отсутствовал на предыдущем шаге) и загрузите исходный архив на страницу релиза.
• Возьмите tar-архив «github-binaries.tar» из «c_release_binaries» запуска помеченного коммита в circle-ci и добавьте все двоичные файлы из него на страницу релиза. Убедитесь, что он содержит четыре двоичных файла: «solc-windows.exe», «solc-macos», «solc-static-linux» и «soljson.js».
• Возьмите tar-архив «solc-bin-binaries.tar» из «c_release_binaries» запуска помеченного коммита в circle-ci и добавьте все двоичные файлы из него в solc-bin.
• Если у вас есть чистая проверка репозитория solc-bin, запустите «npm install».
• В «solc-bin» запустите «npm run update -- --reuse-hashes» и убедитесь, что скрипт правильно обновил файлы «list.js», «list.txt» и «list.json», и что символические ссылки на новый релиз были добавлены в «solc-bin/wasm/» и «solc-bin/emscripten-wasm32/».
• Создайте запрос на вытягивание в solc-bin и объедините.

Homebrew и MacOS

• Обновите версию и хэш («sha256sum solidity_$VERSION.tar.gz») в формуле «solidity» в основном репозитории Homebrew.

Docker

• Выполните «./scripts/docker_deploy_manual.sh v$VERSION».

PPA

• Создайте «.release_ppa_auth» в корне вашей локальной проверки Solidity и установите «LAUNCHPAD_EMAIL» и «LAUNCHPAD_KEYID» на адрес электронной почты вашего ключа и идентификатор ключа.
• Дважды проверьте, что список «DISTRIBUTIONS» в «scripts/release_ppa.sh» и «scripts/deps-ppa/static_z3.sh» содержит самые последние версии Ubuntu.
• Убедитесь, что репозиторий PPA «~ethereum/cpp-build-deps» содержит сборки «libz3-static-dev» для всех текущих версий Ubuntu. Обратите внимание, что это может быть включено в мультипакет «z3-статический» (следуйте ссылке «Просмотреть детали пакета», чтобы проверить). Если нет, выполните «scripts/deps-ppa/static_z3.sh» и дождитесь успешного завершения сборок, прежде чем продолжить.
• Выполните «scripts/release_ppa.sh v$VERSION», чтобы создать выпуск PPA. Это создаст один пакет, содержащий статический двоичный файл для старых версий Ubuntu, в репозитории PPA «~ethereum/ethereum-static», и отдельные пакеты с динамически связанными двоичными файлами для последних версий (перечисленных в «DISTRIBUTIONS») в репозитории PPA «~ethereum/ethereum».
• Подождите, пока сборка будет завершена и опубликована для всех архитектур. В настоящий момент мы собираем только для amd64, но в будущем можем добавить arm.

СЕРЬЁЗНО: НЕ ПРОДОЛЖАЙТЕ РАНЕЕ!!!

• После публикации пакета со статической сборкой используйте его для создания пакетов для старых версий Ubuntu. Скопируйте статический пакет в PPA ~ethereum/ethereum для целевых серий Trusty, Xenial и Bionic, выбрав «Копировать существующие двоичные файлы».

Выпуск solc-js

• Дождитесь правильного развёртывания solc-bin. Вы можете проверить это через remix — тестовый запуск через remix в любом случае рекомендуется.
• Увеличьте номер версии, создайте запрос на вытягивание (pull request) для этого, объедините его после успешного прохождения тестов.
• Создайте тег с помощью команды git tag --annotate v$VERSION и отправьте его с помощью git push --tags.
• Подождите завершения CI-запусков для самого тега.
• Возьмите артефакт solc-x.y.z.tgz из build-package, запущенного на помеченном коммите в circle-ci. Проверьте архив tar, чтобы убедиться, что он содержит актуальный бинарный файл компилятора (soljson.js).
• Запустите npm publish solc-x.y.z.tgz, чтобы опубликовать только что созданный архив tar.

После выпуска

• Убедитесь, что документация для нового выпуска была успешно опубликована. Перейдите на страницу состояния документации на ReadTheDocs и убедитесь, что новая версия указана, работает и отмечена как основная.
• Удалите предупреждение «всё ещё в процессе» из примечаний к выпуску.
• Объедините связанные с выпуском сообщения в блоге.
• Сделайте коммит, чтобы увеличить номер версии в файле CMakeLists.txt на ветке develop и добавьте новую запись в журнал изменений.
• Обновите раздел информации о выпуске в исходном коде soliditylang.org.
• Сообщите об этом в Twitter, включая ссылки на релиз и сообщение в блоге.
• Сообщите об этом на Fosstodon, включая ссылки на релиз и сообщение в блоге.
• Поделитесь объявлением на Reddit в /r/ethdev, а также сделайте кросс-пост в /r/ethereum.
• Поделитесь объявлением на форуме Solidity в категории «Объявления».
• Поделитесь объявлением в Project Updates.
• Поделитесь объявлением в канале #solidity на Matrix.
• Поделитесь объявлением в канале #solc-tooling.
• Если на этот раз что-то пошло не так, упомяните об этом в разделе «Уроки прошлых выпусков».
• Откиньтесь назад, ждите сообщений об ошибках и повторяйте с шага 1 :).