Guía de lanzamiento #
Este documento solo es relevante para los administradores de versiones de Matplotlib.
Una guía para desarrolladores que están haciendo un lanzamiento de Matplotlib.
Nota
Esto supone que hay un control remoto de solo lectura para el repositorio canónico
remote
y un control remoto de lectura/escritura esDANGER
prueba #
Usamos GitHub Actions para la integración continua. Al prepararse para un lanzamiento, la confirmación etiquetada final debe probarse localmente antes de cargarse:
pytest -n 8 .
Además, se debe ejecutar e inspeccionar manualmente la siguiente prueba:
python tools/memleak.py agg 1000 agg.pdf
Además, se debe ejecutar e inspeccionar manualmente lo siguiente, pero actualmente no funciona:
pushd examples/tests/
python backend_driver_sgskip.py
popd
Estadísticas de GitHub #
Extraemos automáticamente el problema de GitHub, los PR y los autores de GitHub a través de la API. Copie el actual doc/users/github_stats.rst
a
doc/users/prev_whats_new/github_stats_X.Y.Z.rst
, cambie el destino del enlace en la parte superior del archivo y elimine la sección "Estadísticas anteriores de GitHub" al final.
Por ejemplo, al actualizar de v3.2.0 a v3.2.1:
cp doc/users/github_stats.rst doc/users/prev_whats_new/github_stats_3.2.0.rst
$EDITOR doc/users/prev_whats_new/github_stats_3.2.0.rst
# Change contents as noted above.
git add doc/users/prev_whats_new/github_stats_3.2.0.rst
Luego vuelva a generar las estadísticas actualizadas:
python tools/github_stats.py --since-tag v3.2.0 --milestone=v3.2.1 --project 'matplotlib/matplotlib' --links > doc/users/github_stats.rst
Revisar y confirmar cambios. Es posible que algunos títulos de problemas/PR no sean reST válidos (el problema más común es *
que se interprete como marcado no cerrado).
Nota
Asegúrese de autenticarse con la API de GitHub. Si no lo hace, GitHub lo bloqueará por superar los límites de tasa de API. Puede autenticarse de una de dos maneras:
usando el
keyring
paquete; y luego, cuando ejecute el script de estadísticas, se le solicitará el nombre de usuario y la contraseña, que se almacenarán en el conjunto de claves de su sistema, o,pip install keyring
usando un token de acceso personal; genere un nuevo token en esta página de GitHub con el
repo:public_repo
alcance y coloque el token en~/.ghoauth
.
Actualice y valide los documentos #
Fusionar *-doc
rama #
Combine la rama 'doc' más reciente (p. ej., v3.2.0-doc
) en la rama que va a etiquetar y elimine la rama doc en GitHub.
Actualice las versiones admitidas en la política de seguridad #
Al realizar versiones principales o secundarias, actualice las versiones admitidas en la Política de seguridad en SECURITY.md
. Por lo general, puede tratarse de una o dos versiones menores anteriores, pero depende de los administradores de versiones.
Actualizar notas de la versión #
Novedades #
Solo se necesita para lanzamientos mayores y menores. Los lanzamientos de corrección de errores no deberían tener nuevas funciones.
Combine el contenido de todos los archivos en doc/users/next_whats_new/
un solo archivo doc/users/prev_whats_new/whats_new_X.Y.0.rst
y elimine los archivos individuales.
Cambios en la API #
Se necesita principalmente para lanzamientos mayores y menores. A veces podemos tener cambios en la API en las versiones de corrección de errores.
Combine el contenido de todos los archivos en doc/api/next_api_changes/
un solo archivo doc/api/prev_api_changes/api_changes_X.Y.Z.rst
y elimine los archivos individuales.
Notas de la versión TOC #
Actualizar doc/users/release_notes.rst
:
Para lanzamientos mayores y menores agregue una nueva sección
X.Y === .. toctree:: :maxdepth: 1 prev_whats_new/whats_new_X.Y.0.rst ../api/prev_api_changes/api_changes_X.Y.0.rst prev_whats_new/github_stats_X.Y.0.rst
Para lanzamientos de corrección de errores, agregue las estadísticas de GitHub y (si está presente) los cambios de API a la sección XY existente
../api/prev_api_changes/api_changes_X.Y.Z.rst prev_whats_new/github_stats_X.Y.Z.rst
Cambiar de versión de actualización #
Actualizar doc/_static/switcher.json
_ Si es un lanzamiento menor X.Y.Z
, cree una nueva entrada y cambie el nombre de estable
. Si es un lanzamiento principal , cambie el nombre de y agregue una nueva versión para el estable anterior.version: X.Y.(Z-1)
name: stable/X.Y.Z
X.Y.0
name: devel/X.(Y+1)
name: stable/X.Y.0
Verifique que los documentos compilan #
Finalmente, asegúrese de que los documentos se construyan limpiamente.
make -Cdoc O=-j$(nproc) html latexpdf
Una vez creados los documentos, compruebe que todos los enlaces, internos y externos, siguen siendo válidos. Usamos linkchecker
para esto, que aún no ha sido portado a Python3. Deberá crear un entorno de Python2 con un verificador de
requests==2.9.0
enlaces
conda create -p /tmp/lnkchk python=2 requests==2.9.0
source activate /tmp/lnkchk
pip install linkchecker
pushd doc/build/html
linkchecker index.html --check-extern
popd
Abordar cualquier problema que pueda surgir. Los enlaces internos se verifican en Circle CI, esto solo debería marcar los enlaces externos fallidos.
Actualice las versiones compatibles en SECURITY.md #
Para la versión secundaria, actualice la tabla SECURITY.md
para especificar que se admiten las 2 versiones secundarias más recientes de la serie de versiones principales actual.
Para el lanzamiento de una versión principal, actualice la tabla SECURITY.md
para especificar que la última versión secundaria de la serie de versiones principales anterior aún es compatible. La eliminación del soporte para la última versión de una serie de versiones principales se gestionará de forma ad hoc.
Crear compromiso de lanzamiento y etiquetar #
Para crear la etiqueta, primero cree una confirmación vacía con un conjunto muy conciso de las notas de la versión en el mensaje de confirmación.
git commit --allow-empty
y luego cree una etiqueta firmada y anotada con el mismo texto en el mensaje del cuerpo
git tag -a -s v2.0.0
que le pedirá la contraseña de su clave GPG y una anotación. Para prelanzamientos es importante seguirPEP 440 para que los artefactos de compilación se clasifiquen correctamente en PyPI.
Para evitar problemas con los constructores posteriores que descargan el tarball de GitHub, es importante alejar todas las ramas de la confirmación con la etiqueta [ 1 ] :
git commit --allow-empty
Finalmente, envíe la etiqueta a GitHub:
git push DANGER main v2.0.0
¡Felicitaciones, la parte más aterradora está hecha!
Si se trata de una versión final, cree también una rama 'doc' (esto no se hace para versiones preliminares):
git branch v2.0.0-doc
git push DANGER v2.0.0-doc
y si se trata de una versión principal o secundaria, también cree una rama de corrección de errores (se eliminará una versión micro de esta rama):
git branch v2.0.x
En esta rama, elimine los comentarios de los globos de Actualizar y valide los documentos . Y entonces
git push DANGER v2.0.x
Gestión de versiones / DOI #
A través de la interfaz de usuario de GitHub , convierta la etiqueta recién enviada en un lanzamiento. Si se trata de un prelanzamiento, recuerde marcarlo como tal.
Para los lanzamientos finales, también obtenga el DOI de zenodo (que automáticamente producirá uno una vez que se presione la etiqueta). Agregue el arreglo posterior de doi y la versión al diccionario
tools/cache_zenodo_svg.py
y ejecute el script.
Esto descargará el nuevo svg al _static
directorio en los documentos y lo editará doc/citing.rst
. Confirme el nuevo svg, el cambio a tools/cache_zenodo_svg.py
y los cambios a
doc/citing.rst
la rama VER-doc y empuje a GitHub.
git checkout v2.0.0-doc
$EDITOR tools/cache_zenodo_svg.py
python tools/cache_zenodo_svg.py
$EDITOR doc/citing.html
git commit -a
git push DANGER v2.0.0-doc:v2.0.0-doc
Construyendo binarios #
Distribuimos macOS, Windows y muchas ruedas de Linux, así como un tarball fuente a través de PyPI. La mayoría de los constructores deberían activarse automáticamente una vez que la etiqueta se envía a GitHub:
Las ruedas de Windows, macOS y manylinux se basan en GitHub Actions. Las compilaciones se activan mediante la acción de GitHub definida en
.github/workflows/cibuildwheel.yml
y las ruedas estarán disponibles como artefactos de la compilación.Christoph Gohlke crea ruedas de Windows alternativas automáticamente y estarán disponibles en su sitio una vez construidas.
El bot de marcación automática debería abrir una solicitud de extracción en la materia prima de conda-forge . Revisa y fusiona (si tienes el poder de hacerlo).
Advertencia
Debido a que esto está automatizado, es extremadamente importante eliminar todas las ramas de la etiqueta, como se explica en Crear confirmación y etiqueta de lanzamiento .
Si se trata de una versión final, se debe contactar a los siguientes empaquetadores intermedios:
Debian
Fedora
Arco
Gentoo
Macports
Cerveza casera
continuo
pensado
Esto se puede hacer antes de recopilar todos los archivos binarios y cargarlos en pypi.
Hacer distribución y subir a PyPI #
Una vez que haya recolectado todas las ruedas (espere que esto tome alrededor de un día), genere el tarball
git checkout v2.0.0
git clean -xfd
python setup.py sdist
y copie todas las ruedas en el dist
directorio. Primero, verifique que los archivos dist estén bien
twine check dist/*
y luego use twine
para cargar todos los archivos a pypi
twine upload -s dist/matplotlib*tar.gz
twine upload dist/*whl
¡Felicitaciones, ahora has hecho la segunda parte más aterradora!
Documentación de compilación e implementación #
Para crear la documentación, debe tener instalada la versión etiquetada, pero cree los documentos desde la ver-doc
rama. Una manera fácil de arreglar esto es:
pip install matplotlib
pip install -r requirements/doc/doc-requirements.txt
git checkout v2.0.0-doc
git clean -xfd
make -Cdoc O="-t release -j$(nproc)" html latexpdf LATEXMKOPTS="-silent -f"
que construirá la versión html y pdf de la documentación.
La documentación construida existe en el repositorio matplotlib.github.com . Al presionar los cambios en la página principal, se actualiza automáticamente el sitio web.
La documentación está organizada por versión. En la raíz del árbol siempre se encuentra la documentación de la última versión estable. Debajo de eso, hay directorios que contienen la documentación para versiones anteriores. La documentación para main actual se basa en Circle CI y se envía al repositorio devdocs . Estos están disponibles en matplotlib.org/devdocs .
Suponiendo que tiene este repositorio desprotegido en el mismo directorio que matplotlib
cd ../matplotlib.github.com
mkdir 2.0.0
rsync -a ../matplotlib/doc/build/html/* 2.0.0
cp ../matplotlib/doc/build/latex/Matplotlib.pdf 2.0.0
que copiará los documentos creados. Si se trata de una versión final, vincule el
stable
subdirectorio a la versión más reciente:
rsync -a 2.0.0/* ./
rm stable
ln -s 2.0.0/ stable
Deberá editar manualmente versions.html
para mostrar las últimas 3 versiones etiquetadas. También deberá editar sitemap.xml
para incluir la versión recién lanzada. Ahora confirme y envíe todo a GitHub
git add *
git commit -a -m 'Updating docs for v2.0.0'
git push DANGER main
¡Felicitaciones, ahora has hecho la tercera parte más aterradora!
Si tiene acceso, borre los cachés de Cloudflare.
Por lo general, GitHub tarda entre 5 y 10 minutos en procesar el envío y actualizar la página web en vivo (recuerde borrar la memoria caché de su navegador).
anunciando #
El paso final es anunciar el lanzamiento al mundo. Se debe enviar una versión corta de las notas de la versión junto con los agradecimientos a
Para los lanzamientos finales, los anuncios también deben enviarse a las listas de correo numpy/scipy/scikit-image.
Además, se deberán realizar anuncios en redes sociales (twitter a través de la @matplotlib
cuenta, cualquier otro a través de cuentas personales).
Se debe contactar a NumFOCUS para incluirlo en su boletín informativo.
Paquetes Conda #
El proyecto Matplotlib en sí no libera paquetes conda. En particular, el administrador de versiones de Matplotlib no es responsable del empaquetado de conda.
Para obtener información sobre el paquete de Matplotlib para conda-forge, consulte https://github.com/conda-forge/matplotlib-feedstock .