Las siguientes instrucciones son para el administrador de liberaciones, y detallan cómo liberar una nueva versión oficial.

Betas

  • En un punto donde la rama master esté sana (se superen todas las pruebas y no haya regresiones conocidas): mezcla master en beta.
  • Al menos una semana después de mezclar master en beta, añade una etiqueta beta1. Por ejemplo: release-2019.1beta1. Al etiquetar la beta esta se mostrará en la página versiones de desarrollo, y el sistema de actualizaciones automáticas comenzará a ofrecerla a aquellos que busquen betas.
  • Mira periódicamente las incidencias recientes archivadas, específicamente las etiquetadas como p1, crash o appcrash.
  • Mira periódicamente las solicitudes de cambio basadas en beta y asegúrate de que son revisadas y luego aprobadas / mezcladas o rechazadas.
  • Tras la beta final, congela las traducciones durante 2 semanas. En este momento no deberían llegar más commits a la rama beta.
  • Según se vayan mezclando solicitudes de cambio basadas en la rama beta, crea nuevas etiquetas.

Candidatas a liberación

  • Comprueba que es seguro liberar una rc mirando las incidencias recientes, especialmente aquellas etiquetadas como p1, crash o appcrash.
  • Si se trata de la rc1, actualiza las traducciones:
    1. Inicia sesión en exbi y cambia con el comando su al usuario nvdal10n.
    2. cd ~/mr/mainNVDACode
    3. mr up
    4. cd ../srt
    5. mr up
    6. mr svn2nvda
  • Si se trata de la rc1, restablece la rama rc a beta. De lo contrario, mezcla rc en beta si es necesario.
  • Para todas las demás candidatas a liberación, busca cualquier solicitud de cambio basada en rc, revísalas y acepta / mezcla o rechaza según corresponda.
  • Crea una etiqueta anotada para la liberación con el prefijo «release-«. Por ejemplo, release-2016.1rc1.
  • Esto iniciará una construcción con AppVeyor, tendrás que esperar a que se complete. Como parte de esto, se lanzará la liberación.
  • Publica la versión liberada. En exbi, cambia al usuario nvaccess y ejecuta nvdaRelease
  • Si es una liberación candidata, crea una entrada de blog en www.nvaccess.org. Ponla en la categoría en desarrollo, y nunca en la de noticias.
    • Usa como base una publicación anterior.
    • Si no es la primera liberación candidata, incluye los cambios desde la liberación candidata anterior.
  • Difunde la publicación en la lista de traductores de NVDA, la lista de desarrolladores y Twitter.
  • Escanea el archivo del instalador en Virus Total. Pon directamente la URL de descarga.
  • Si es una liberación final:
  • Marca el hito de lanzamiento como completado en GitHub.
  • Cambia el conjunto de hitos de las incidencias y las peticiones de cambios automáticamente cerradas por GitHub a la siguiente liberación:
    1. Consigue el id del hito para la nueva liberación. La forma más fácil de hacerlo es ir a https://github.com/nvaccess/nvda/milestones y mirar el enlace del hito en cuestión. El número del final es el id.
    2. En exbi, edita ~nvaccess/data/nvaServer.conf.
    3. En la sección [nvdaGithub], cambia el valor de autoCloseMilestone al identificador del hito que has obtenido en el paso 1.
    4. Recarga uwsgi para que los cambios tengan efecto: sudo systemctl reload uwsgi
  • Crea una entrada de blog en www.nvaccess.org bajo la categoría liberaciones.
  • Publica la noticia en Facebook.
  • Publica la noticia en la lista de correo de noticias de NV Access.
  • Si no se ha hecho ya, prepara la rama master para la siguiente versión (la que va después de la que se ha publicado):
    1. En source/versionInfo.py, actualiza las variables version_year y/o version_major para la próxima versión. Si la próxima versión es la primera del año en curso, (por ejemplo, 2018.1), actualiza copyrightYears también.
    2. Añade un encabezado para la siguiente versión en user_docs/en/changes.t2t.