Выпуск версии

Как подготовить выпуск

Этот файл предоставляет обзор того, что необходимо для создания двоичных выпусков NumPy.

Текущая информация о сборке и выпуске

Текущая информация о сборке и выпуске NumPy и SciPy разбросана по нескольким местам. Она должна быть обобщена в одном месте, обновлена и, при необходимости, описана более подробно. Разделы ниже перечисляют все места, где можно найти полезную информацию.

Дерево исходного кода

INSTALL.rst.txt
release.sh
pavement.py

Документация NumPy

https://github.com/numpy/numpy/blob/master/doc/HOWTO_RELEASE.rst.txt

Wiki SciPy.org

https://www.scipy.org/Installing_SciPy и ссылки на этой странице.

Сценарии выпуска

https://github.com/numpy/numpy-vendor

Поддерживаемые платформы и версии

NEP 29 описывает, какие версии Python поддерживаются; в первой половине 2020 года это будет Python >= 3.6. Мы тестируем NumPy на всех этих версиях каждый раз, когда объединяем код в мастер. Двоичные установщики могут быть доступны для подмножества этих версий (см. ниже).

OS X

Поддерживаются версии OS X >= 10.9, информация о поддержке версий Python находится в NEP 29. Мы собираем двоичные файлы wheel для OSX, совместимые с Python с python.org, системным Python, homebrew и macports — см. этот сводный обзор сборки wheel для OSX для получения подробной информации.

Windows

Мы собираем 32- и 64-разрядные файлы wheel на Windows. Поддерживаются Windows 7, 8 и 10. Мы собираем NumPy с помощью инструментария mingw-w64 на Appveyor.

Linux

Мы собираем и распространяем файлы wheel manylinux1 для NumPy. Многие дистрибутивы Linux включают собственные двоичные сборки NumPy.

BSD / Solaris

Двоичные файлы не предоставляются, но были сообщения об успешной сборке на Solaris и BSD.

Инструментарий

Мы собираем все наши файлы wheel на облачной инфраструктуре — поэтому этот список компиляторов предназначен для справки и отладки сборок локально. См. сценарии .travis.yml и appveyor.yml в репозитории numpy wheels для получения окончательного источника рецептов сборки. Упаковки, доступные с помощью pip, отмечены.

Компиляторы

Для каждой платформы используется та же версия gcc, что и для сборки самого Python. В настоящее время это означает:

Сборки OS X на travis в настоящее время используют clang. Похоже, что двоичные wheel для OSX >= 10.6 могут быть безопасно собраны из виртуальных машин travis-ci OS X 10.9, когда сборка выполняется против Python из установщиков python.org;
Сборки Windows используют инструментарий mingw-w64;
Файлы wheel manylinux1 используют gcc, предоставленный в образах контейнеров Manylinux.

Вам понадобится Cython для сборки двоичных файлов. Cython компилирует файлы .pyx в дистрибутиве NumPy в файлы .c.

OpenBLAS

Все файлы wheel ссылаются на версию OpenBLAS, предоставленную через репозиторий openblas-libs. Объектный файл (или DLL) поставляется вместе с файлом wheel и переименовывается для предотвращения конфликтов имен с другими объектами shared object OpenBLAS, которые могут существовать в файловой системе.

Сборка исходных архивов и файлов wheel

Для запуска сборок wheel необходимо иметь права записи для numpy-wheels.

Python(ы) с сайта python.org или из дистрибутива Linux.
cython (pip)
virtualenv (pip)
Paver (pip)
pandoc pandoc.org или из дистрибутива Linux.
numpy-wheels https://github.com/MacPython/numpy-wheels (клонировать)

Сборка документации

Для сборки документов требуется ряд файлов latex .sty. Установите их все, чтобы избежать проблем.

Sphinx (pip)
numpydoc (pip)
Matplotlib
Texlive (или MikTeX на Windows)

Загрузка на PyPI

terryfy https://github.com/MacPython/terryfy (клонировать).
beautifulsoup4 (pip)
delocate (pip)
auditwheel (pip)
twine (pip)

Генерация списков авторов/запросов на исправление

Вам потребуется личный доступный токен https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/, чтобы скрипты могли получить доступ к репозиторию NumPy на github.

gitpython (pip)
pygithub (pip)

Virtualenv

Virtualenv — очень полезный инструмент для работы с несколькими версиями пакетов. Он также используется в скрипте Paver для сборки документации.

Что выпущено

Файлы wheel

В настоящее время мы поддерживаем Python 3.6-3.8 на Windows, OSX и Linux

Windows: 32- и 64-разрядные файлы wheel, собранные с помощью Appveyor;
OSX: x64_86 файлы wheel для OSX, собранные с помощью travis-ci;
Linux: 32- и 64-разрядные файлы wheel manylinux1, собранные с помощью travis-ci.

См. репозиторий сборки numpy wheels для получения более подробной информации.

Другое

Заметки к релизу
Журнал изменений

Исходный дистрибутив

Мы собираем исходные релизы в форматах .zip и .tar.gz.

Процесс выпуска

Согласуйте график выпуска

Типичный график выпуска включает одну бета-версию, две версии кандидата на выпуск и окончательный выпуск. Сначала лучше обсудить сроки на почтовой рассылке, чтобы люди успели внести свои правки, объединить правки в wiki документации и т. д. После того, как дата будет установлена, создайте новую ветвь maintenance/x.y.z, добавьте новые пустые заметки к релизу для следующей версии в ветви master и обновите вехи Trac.

Убедитесь, что текущая ветвь правильно собирает пакет

git clean -fxd
python setup.py bdist
python setup.py sdist

Для фактической сборки двоичных файлов после правильной настройки можно использовать сценарий release.sh. Для получения подробностей о самом процессе сборки лучше прочитать сценарий pavement.py.

Примечание

Следующие шаги повторяются для бета-версии(й), версии(й) кандидата на выпуск и окончательного выпуска.

Проверьте устаревшие элементы

Перед созданием ветки выпуска необходимо проверить, что весь устаревший код, который должен быть удален, действительно удален, и все новые устаревшие элементы указывают в строке документации или предупреждении об устаревании, в какой версии код будет удален.

Проверьте номер версии C API

Номер версии C API необходимо отслеживать в трех местах

numpy/core/setup_common.py
numpy/core/code_generators/cversions.txt
numpy/core/include/numpy/numpyconfig.h

Процесс состоит из трех шагов.

Если API изменился, увеличьте C_API_VERSION в setup_common.py. API не изменился только в том случае, если любой код, скомпилированный с использованием текущего API, будет обратной совместим с последней выпущенной версией NumPy. Любые изменения в C-структурах или добавление в общедоступный интерфейс сделают новый API несовместимым с предыдущими версиями.
Если C_API_VERSION на первом шаге изменился или если хеш API изменился, необходимо обновить файл cversions.txt. Для проверки хэша запустите скрипт numpy/core/cversions.py и запишите хэш API, который будет напечатан. Если этот хэш не совпадает с последним хэшем в numpy/core/code_generators/cversions.txt, хэш изменился. Используя соответствующий C_API_VERSION и хэш, добавьте новую запись в cversions.txt. Если версия API не изменилась, но хэш отличается, вам необходимо закомментировать предыдущую запись для этой версии API. Например, в NumPy 1.9 были добавлены аннотации, которые изменили хэш, но API был таким же, как в 1.8. Хеш служит контролем на изменения API, но не является окончательным.

Если шаги 1 и 2 выполнены правильно, компиляция релиза не должна выдавать предупреждение «Обнаружено несоответствие API в начале сборки».
В numpy/core/include/numpy/numpyconfig.h потребуется новая макрокоманда NPY_X_Y_API_VERSION, где X и Y — номер основной и дополнительной версии выпуска. Значение этой макрокоманды необходимо увеличивать только от предыдущей версии, если некоторые функции или макрокоманды в файлах include были устаревшими.

Номер версии C ABI в numpy/core/setup_common.py следует обновлять только для основных релизов.

Проверка заметок к выпуску

Используйте towncrier для создания заметок к выпуску и внесения изменений. Это удалит все фрагменты из doc/release/upcoming_changes и добавит doc/release/<version>-note.rst. Обратите внимание, что в настоящее время towncrier необходимо установить из ветки master, так как последняя версия (19.2.0) устарела.

towncrier –version “<version>” git commit -m”Создать заметки к релизу”

Проверьте, что заметки к релизу актуальны.

Обновите заметки к релизу, добавив раздел «Основные моменты». Укажите некоторые из следующих пунктов:

новые основные функции
устаревшие и удаленные функции
поддерживаемые версии Python
для SciPy, поддерживаемые версия(и) NumPy
перспективы ближайшего будущего

Обновление статуса выпуска и создание тега выпуска

Определите хэш коммита выпуска, например, 1b2e1d63ff.

::: git co 1b2e1d63ff # дает предупреждение об отсоединении головки

Сначала измените/проверьте следующие переменные в pavement.py в зависимости от версии выпуска:

RELEASE_NOTES = 'doc/release/1.7.0-notes.rst'
LOG_START = 'v1.6.0'
LOG_END = 'maintenance/1.7.x'

Внесите другие изменения. Когда вы будете готовы к выпуску, выполните следующие действия:

diff --git a/setup.py b/setup.py
index b1f53e3..8b36dbe 100755
--- a/setup.py
+++ b/setup.py
@@ -57,7 +57,7 @@ PLATFORMS           = ["Windows", "Linux", "Solaris", "Mac OS-
 MAJOR               = 1
 MINOR               = 7
 MICRO               = 0
-ISRELEASED          = False
+ISRELEASED          = True
 VERSION             = '%d.%d.%drc1' % (MAJOR, MINOR, MICRO)

 # Return the git revision as a string

И убедитесь, что переменная VERSION настроена правильно.

Теперь можно создать коммит и тег выпуска. Мы рекомендуем не отправлять коммит или тег сразу же, на случай если потребуется дополнительная очистка. Мы предпочитаем отложить отправку тега до тех пор, пока мы не уверены, что это окончательная форма выпущенного кода (см.: Отправка тега и коммита выпуска):

git commit -s -m “REL: Выпуск.” setup.py git tag -s <version>

Флаг -s создает тег, подписанный PGP (обычно GPG). Пожалуйста, подписывайте теги выпусков.

Тег выпуска должен содержать номер выпуска в аннотации (сообщении тега). К сожалению, имя тега можно изменить без нарушения подписи, но содержимое сообщения нельзя.

См.: https://github.com/scipy/scipy/issues/4919 для обсуждения подписи тегов выпуска и https://keyring.debian.org/creating-key.html для получения инструкций по созданию ключа GPG, если у вас его нет.

Чтобы сделать ваш ключ более узнаваемым, рассмотрите возможность отправки вашего ключа на общедоступные серверы ключей, используя команду, например:

gpg --send-keys <yourkeyid>

Обновить версию ветки master

Увеличьте номер выпуска в setup.py. Кандидаты на выпуск должны иметь «rc1» (или «rc2», «rcN») добавленные к формату X.Y.Z.

Также создайте новый хэш версии в cversions.txt и соответствующее определение версии NPY_x_y_API_VERSION в numpyconfig.h

Запустить сборку wheel

См. репозиторий MacPython/numpy wheels.

В этом репозитории отредактируйте файлы:

azure/posix.yml
azure/windows.yml.

В обоих случаях установите переменную BUILD_COMMIT на текущий тег выпуска - например, v1.19.0:

$ gvim azure/posix.yml azure/windows.yml
$ git commit -a
$ git push upstream HEAD

Убедитесь, что тег выпуска был отправлен.

Запустите сборку, отправив коммит ваших изменений в репозиторий. Обратите внимание, что вы можете сделать это на ветке, но ее необходимо отправить в upstream в репозиторий MacPython/numpy-wheels для запуска загрузок, так как только этот репозиторий имеет соответствующие токены для разрешения загрузок.

Собраные wheel-файлы появятся по адресу https://anaconda.org/multibuild-wheels-staging/numpy

Произвести выпуск

Сгенерировать журнал изменений и заметки для загрузки с помощью:

paver write_release

Собрать и заархивировать документацию

Сделайте:

cd doc/
make dist

чтобы проверить, что документация находится в состоянии, готовом к сборке. Затем, после маркировки, создайте архив документации в репозитории numpy/doc:

# This checks out github.com/numpy/doc and adds (``git add``) the
# documentation to the checked out repo.
make merge-doc
# Now edit the ``index.html`` file in the repo to reflect the new content.
# If the documentation is for a non-patch release (e.g. 1.19 -> 1.20),
# make sure to update the ``stable`` symlink to point to the new directory.
ln -sfn <latest_stable_directory> stable
# Commit the changes
git -C build/merge commit -am "Add documentation for <version>"
# Push to numpy/doc repo
git -C build/merge push

Обновить PyPI

Wheels и исходные файлы должны быть загружены на PyPI.

Сначала необходимо загрузить wheels, а затем исходные форматы, чтобы убедиться, что пользователи pip случайно не получат установку исходного кода, когда ожидали бинарную wheel-установку.

Вы можете сделать это автоматически с помощью скрипта wheel-uploader из https://github.com/MacPython/terryfy. Вот рекомендуемая команда для скачивания всех Windows, Manylinux, OSX wheel-файлов и загрузки их на PyPI.

NPY_WHLS=~/wheelhouse   # local directory to cache wheel downloads
CDN_URL=https://anaconda.org/multibuild-wheels-staging/numpy/files
wheel-uploader -u $CDN_URL -w $NPY_WHLS -v -s -t win numpy 1.11.1rc1
wheel-uploader -u $CDN_URL -w warehouse -v -s -t macosx numpy 1.11.1rc1
wheel-uploader -u $CDN_URL -w warehouse -v -s -t manylinux1 numpy 1.11.1rc1

Флаг -v обеспечивает подробную обратную связь, а -s заставляет скрипт подписывать wheels с помощью вашего ключа GPG перед загрузкой. Не забудьте загрузить wheels перед исходным tar-архивом, чтобы не было периода, в течение которого пользователи переключаются с ожидаемой бинарной установки на установку исходного кода с PyPI.

Существует два способа обновить выпуск исходного кода на PyPI, первый из них:

$ git clean -fxd  # to be safe
$ python setup.py sdist --formats=gztar,zip  # to check
# python setup.py sdist --formats=gztar,zip upload --sign

Это затребует вашу фразу-пароль к PGP-ключу, чтобы подписать сгенерированные исходные пакеты.

Второй способ - загрузить файл PKG_INFO в директорию sdist в веб-интерфейсе PyPI. Исходный tar-архив также можно загрузить через этот интерфейс.

Отправка тега и коммита выпуска

Наконец, теперь, когда вы уверены, что этот тег правильно определяет выпущенный исходный код, вы можете отправить тег и коммит выпуска в github:

git push  # Push release commit
git push upstream <version>  # Push tag named <version>

где upstream указывает на основной репозиторий https://github.com/numpy/numpy.git.

Обновление scipy.org

Объявление о выпуске с ссылкой на сайт загрузки должно быть размещено в боковой панели главной страницы scipy.org.

Обновление scipy.org должно быть представлено в виде PR на https://github.com/scipy/scipy.org. Файл, который нужно изменить, - www/index.rst. Найдите News.

Объявление спискам рассылки

Выпуск следует объявить в списках рассылки NumPy и SciPy, python-announce, а также, возможно, в списках рассылки Matplotlib, IPython и/или Pygame.

В период бета-тестирования/RC-тестирования на список рассылки следует разместить явное требование проверить бинарные файлы с несколькими другими библиотеками (SciPy/Matplotlib/Pygame).

Объявление в Linux Weekly News

Отправьте письмо редактору LWN, чтобы сообщить о выпуске. Инструкции по адресу: https://lwn.net/op/FAQ.lwn#contact

После окончательного выпуска

После объявления окончательного выпуска остаются несколько административных задач:

Перенос изменений из ветки выпуска в заметки о выпуске и скрипты выпуска, если таковые имеются, в ветку master.
Обновление задач в Trac.

Пошаговые инструкции

Этот файл содержит пошаговое руководство по выпуску NumPy 1.19.0 на Linux, изменённое для сборки на azure и загрузки на anaconda.org. Команды можно скопировать в командную строку, но убедитесь, что вы заменили 1.19.0 на правильную версию.

Этот файл следует читать вместе с общими инструкциями в releasing.

Подготовка к выпуску

Обратный перенос запросов на добавление

Изменения, которые были помечены для этого выпуска, должны быть перенесены в ветку maintenance/1.19.x.

Обновить документацию выпуска

Файл doc/changelog/1.19.0-changelog.rst должен быть обновлен, чтобы отразить окончательный список изменений и участников. Этот текст можно сгенерировать с помощью:

$ python tools/changelog.py $GITHUB v1.18.0..maintenance/1.19.x > doc/changelog/1.19.0-changelog.rst

где GITHUB содержит ваш github-токен доступа. Этот текст также может быть добавлен к doc/release/1.19.0-notes.rst для патчей, но не для новых релизов, таких как 1.19.0, поскольку журналы изменений для *.0 выпусков имеют тенденцию быть чрезмерно длинными. Файл doc/source/release.rst также должен быть обновлён с ссылкой на новые заметки о выпуске. Эти изменения должны быть внесены в ветку maintenance, а затем перенесены в master. Журнал изменений следует проверить на дубликаты имен или короткие имена, и при необходимости обновить файл .mailmap.

Завершение заметки о выпуске

Заполните заметку о выпуске doc/release/1.19.0-notes.rst, указав существенные изменения.

Процедура выпуска

Обратите внимание, что в приведенных ниже фрагментах кода upstream относится к основному репозиторию на github, а origin — к вашей вилке в личном аккаунте. Вам может потребоваться внести коррективы, если вы не создавали вилку репозитория, а просто клонировали его локально. Вы также можете отредактировать .git/config и добавить upstream, если это не сделано.

Подготовка коммита к релизу

Переключитесь на ветку для выпуска, убедитесь, что она актуальна, и очистите репозиторий:

$ git checkout maintenance/1.19.x
$ git pull upstream maintenance/1.19.x
$ git submodule update
$ git clean -xdfq

Отредактируйте pavement.py и setup.py, как подробно описано в HOWTO_RELEASE:

$ gvim pavement.py setup.py  # Generally only setup.py needs updating
$ git commit -a -m"REL: NumPy 1.19.0 release."

Проверка корректности:

$ python3 runtests.py -m "full"

Отправьте этот выпуск непосредственно в конец ветки maintenance. Это требует права записи в репозиторий numpy:

$ git push upstream HEAD

Сборка исходных релизов

Для сборки исходных релизов используется павер. Он создаст каталоги release и release/installers и поместит исходные релизы *.zip и *.tar.gz в последний.

$ python3 -m cython --version  # check for correct cython version
$ paver sdist  # sdist will do a git clean -xdfq, so we omit that

Сборка wheel

Запустите сборку wheel, указав репозиторий numpy-wheels на этот коммит. Это может занять до часа. Репозиторий numpy-wheels клонируется из https://github.com/MacPython/numpy-wheels. Если это первый выпуск в серии, начните с pull, так как репозиторий мог быть изменён другим пользователем, затем создайте новую ветку для серии. Если ветка уже существует, пропустите этот шаг:

$ cd ../numpy-wheels
$ git co master
$ git pull upstream master
$ git branch v1.19.x

Переключитесь на новую ветку и отредактируйте файлы azure-pipelines.yml и .travis.yml, чтобы убедиться, что они содержат правильную версию, и вставьте хэш коммита для коммита REL, созданного выше, для BUILD_COMMIT. Файлы azure/posix.yml и .travis.yml также могут потребовать обновления версий Cython для соответствия версиям Python, но обычно просто сделайте:

$ git checkout v1.19.x
$ gvim azure-pipelines .travis.yml
$ git commit -a -m"NumPy 1.19.0 release."
$ git push upstream HEAD

Теперь подождите. Если вы волнуетесь из-за длительности процесса — сборка может занять некоторое время — вы можете отслеживать процесс сборки, следуя ссылкам, предоставленным на https://github.com/MacPython/numpy-wheels, чтобы проверить статус сборки. Убедитесь, что все необходимые wheel-файлы были собраны и загружены в репозиторий staging перед продолжением.

Обратите внимание, что иногда сборки, как и тесты, терпят неудачу по независящим причинам, и их потребуется перезапустить. Вам потребуется войти под именем «numpy» для этого на azure.

Загрузка wheel

После успешной сборки и подготовки всех wheel-файлов, загрузите их из каталога Anaconda staging с помощью скрипта tools/download-wheels.py:

$ cd ../numpy
$ python3 tools/download-wheels.py 1.19.0

Генерация файлов README

Это необходимо сделать после загрузки всех установщиков, но перед обновлением файла pavement для дальнейшего развития:

$ paver write_release

Поставить тег на релиз

После сборки и загрузки wheel-файлов без ошибок, поставьте тег на коммит REL, подписав его с помощью своего ключа gpg:

$ git tag -s -m"NumPy 1.19.0 release" v1.19.0

Вы должны загрузить свой открытый ключ gpg на github, чтобы тег отображался как «проверенный» там.

Убедитесь, что файлы в release/installers содержат правильные версии, затем отправьте тег в upstream:

$ git push upstream v1.19.0

Мы ждем до этого момента, чтобы отправить тег, потому что он публичный и не должен меняться после отправки.

Сбросить ветку maintenance в состояние разработки

Добавьте еще один REL коммит в ветку обслуживания numpy, который сбрасывает флаг ISREALEASED на значение False и увеличивает счётчик версии:

$ gvim pavement.py setup.py

Создайте заметки к релизу для следующего релиза и отредактируйте их, чтобы установить версию:

$ cp doc/source/release/template.rst doc/source/release/1.19.1-notes.rst
$ gvim doc/source/release/1.19.1-notes.rst
$ git add doc/source/release/1.19.1-notes.rst

Добавьте новые заметки к релизу в список релизов документации:

$ gvim doc/source/release.rst

Зафиксируйте результат:

$ git commit -a -m"REL: prepare 1.19.x for further development"
$ git push upstream HEAD

Загрузка на PyPI

Загрузите на PyPI с помощью twine. После недавних изменений на PyPI требуется недавняя версия twine, здесь использовалась версия 3.1.1:

$ cd ../numpy
$ twine upload release/installers/*.whl
$ twine upload release/installers/numpy-1.19.0.zip  # Upload last.

Если одна из команд прервётся в процессе, вам может потребоваться выборочно загрузить оставшиеся файлы, так как PyPI не позволяет загружать один и тот же файл дважды. Файл исходного кода следует загрузить последним, чтобы избежать проблем с синхронизацией, которые могут возникнуть, если пользователи pip получат доступ к файлам во время загрузки. Обратите внимание, что PyPI допускает только одно распределение исходного кода, здесь мы выбрали архив zip.

Загрузка файлов на github

Перейдите по адресу https://github.com/numpy/numpy/releases, там должна быть v1.19.0 tag, нажмите кнопку редактирования для этой метки. Существует два способа добавления файлов: использование текстового окна для редактирования и загрузка бинарных файлов. Скопируйте содержимое файла release/README.md в текстовое окно. Вам, вероятно, придётся внести некоторые правки, чтобы оно выглядело правильно. Затем

Загрузите release/installers/numpy-1.19.0.tar.gz как бинарный файл.
Загрузите release/installers/numpy-1.19.0.zip как бинарный файл.
Загрузите release/README.rst как бинарный файл.
Загрузите doc/changelog/1.19.0-changelog.rst как бинарный файл.
Установите флажок предварительной версии, если это предварительный релиз.
Нажмите кнопку {Publish,Update} release внизу.

Загрузка документов на numpy.org

Этот шаг необходим только для финальных релизов и может быть пропущен для предварительных релизов. make merge-doc клонирует репозиторий numpy/doc в doc/build/merge и обновляет его с новой документацией:

$ pushd doc
$ make dist
$ make merge-doc
$ popd

Если серия релизов новая, вам потребуется добавить новый раздел на главную страницу doc/build/merge/index.html сразу после комментария «вставить здесь»:

$ gvim doc/build/merge/index.html +/'insert here'

В противном случае необходимо обновить только ссылки zip и pdf с новым именем тега:

$ gvim doc/build/merge/index.html +/'tag v1.19'

Вы можете выполнить «тестовый запуск» новой документации в браузере, чтобы убедиться, что ссылки работают:

$ firefox doc/build/merge/index.html

После того, как всё кажется удовлетворительным, зафиксируйте и загрузите изменения:

$ pushd doc/build/merge
$ git commit -am"Add documentation for v1.19.0"
$ git push
$ popd

Объявление о релизе на scipy.org

Предполагается, что вы откромковали https://github.com/scipy/scipy.org:

$ cd ../scipy.org
$ git checkout master
$ git pull upstream master
$ git checkout -b numpy-1.19.0
$ gvim www/index.rst # edit the News section
$ git commit -a
$ git push origin HEAD

Теперь перейдите в свой форк и создайте запрос на вытягивание для ветки.

Объявление на списках рассылки

Релиз должен быть объявлен на списках рассылки numpy-discussion, scipy-devel, scipy-user и python-announce-list. Обратите внимание на предыдущие объявления для базового шаблона. Список авторов и список запросов на вытягивание такие же, как и сгенерированные для заметок к релизу выше. Если вы публикуете сообщение в нескольких списках, убедитесь, что python-announce-list имеет BCC, чтобы ответы не отправлялись в этот список.

Задачи после выпуска

Переключитесь на master и перенесите изменения в документацию:

$ git checkout -b post-1.19.0-release-update
$ git checkout maintenance/1.19.x doc/source/release/1.19.0-notes.rst
$ git checkout maintenance/1.19.x doc/changelog/1.19.0-changelog.rst
$ git checkout maintenance/1.19.x .mailmap  # only if updated for release.
$ gvim doc/source/release.rst  # Add link to new notes
$ git add doc/changelog/1.19.0-changelog.rst doc/source/release/1.19.0-notes.rst
$ git status  # check status before commit
$ git commit -a -m"REL: Update master after 1.19.0 release."
$ git push origin HEAD

Перейдите на github и создайте запрос на вытягивание.