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

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

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

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

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

Дерево исходных кодов

INSTALL.rst.txt
release.sh
pavement.py

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

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

Вики SciPy.org

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

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

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

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

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

OS X

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

Windows

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

Linux

Мы собираем и распространяем manylinux1 файлы wheel для 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;
Manylinux1 файлы wheel используют GCC, предоставляемый в образах Docker Manylinux.

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

OpenBLAS

Все файлы wheel связаны с версией OpenBLAS, предоставленной через репозиторий openblas-libs. Объектный файл (или DLL) поставляется вместе с файлом wheel и переименовывается для предотвращения конфликтов имён с другими объектами 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 для OS X, созданные с помощью travis-ci;
Linux: 32- и 64-битные файлы wheel Manylinux1, созданные с помощью travis-ci.

Более подробную информацию см. в репозитории сборки numpy wheels.

Другое

Заметки к выпуску
Журнал изменений

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

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

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

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

Типичный график выпуска включает одну бета-версию, две версии кандидатов на выпуск и окончательный выпуск. Лучше сначала обсудить сроки на списке рассылки, чтобы люди успели внести свои коммиты вовремя, объединить правки в вики-документации и т. д. После того, как дата будет согласована, создайте новую ветку maintenance/x.y.z, добавьте пустые заметки к выпуску для следующей версии в ветке main и обновите вехи 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 — основные и второстепенные номера версии выпуска. Значение этой макрокоманды нужно увеличивать только от предыдущей версии, если какие-то функции или макрокоманды в файлах заголовков были помечены как устаревшие.

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

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

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

towncrier build –version “<version>” git commit -m”Create release note”

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

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

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

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

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

::: git co 1b2e1d63ff # выдаёт предупреждение о detached head

Сначала измените/проверьте следующие переменные в 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>

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

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

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

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

См. репозиторий 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

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

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

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

Выпустить

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

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.

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

Вы можете сделать это автоматически, используя скрипт wheel-uploader из https://github.com/MacPython/terryfy. Вот рекомендуемая команда для скачивания всех колес Windows, Manylinux, OSX и загрузки их на 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 заставляет скрипт подписывать колеса вашим ключом GPG перед загрузкой. Не забудьте загрузить колеса перед исходным tarball, чтобы не было периода, когда пользователи переключаются с ожидаемой бинарной установки на установку исходного кода с 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. Исходный tarball также можно загрузить через этот интерфейс.

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

Наконец, теперь, когда вы уверены, что этот тег правильно определяет исходный код, который вы выпустили, вы можете отправить тег и коммит выпуска на 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.

Обновить oldest-supported-numpy

Если этот выпуск — первый, поддерживающий новую версию Python, или первый, предоставляющий колеса для новой платформы или версии PyPy, необходимо обновить версионную привязку в https://github.com/scipy/oldest-supported-numpy. Либо отправьте PR с изменениями в setup.cfg, либо откройте вопрос с информацией о необходимых изменениях.

Оповестить списки рассылки

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

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

Оповестить Linux Weekly News

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

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

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

Переместить изменения из ветки выпуска в заметки о выпуске и скрипты выпуска, если таковые имеются, в главную ветку.
Обновить этапы в 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, а затем будут перенесены в главную ветку. Журнал изменений необходимо проверить на наличие дублирующихся имён или коротких имён, и файл .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

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

Для сборки исходных релизов используется Paver. Он создаст каталоги 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

Сборка колес

Запустите сборку колес, указав репозиторий 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 для проверки статуса сборки. Убедитесь, что все необходимые wheels были собраны и загружены в репозиторий staging перед продолжением.

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

Загрузка колес

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

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

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

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

$ paver write_release

Поставить метку выпуска

После сборки и загрузки колес без ошибок поставьте метку на коммит 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

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

Сброс ветки поддержки в состояние разработки

Добавьте еще один 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 сразу после комментария «insert here»:

$ 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

Обновите стабильную ссылку:

$ ln -sfn 1.19 stable

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

$ 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, чтобы ответы не отправлялись на этот список.

Задачи после релиза

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

$ 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 main after 1.19.0 release."
$ git push origin HEAD

Перейдите на github и создайте PR.