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

Iniciar la beta

  • Decide desde qué commit quieres que empiece la beta.
    • Generalmente master debería estar sana (se superan todas las pruebas y no hay regresiones conocidas)
    • El cambio más reciente (y significativo) en beta debería haber tenido al menos una semana de pruebas en alpha.
  • Mezcla este commit en beta
  • Crea una nueva pre-release con la página de nueva liberación de GitHub
    • Ejemplo de versión de etiqueta: release-2019.2beta3
    • Destino: beta
    • Ejemplo de título de liberación: Release 2019.2beta3
    • No hace falta descripción para la primera beta, en las siguientes betas se pueden describir adiciones o eliminaciones importantes.
    • Asegúrate de que la opción «This is a pre-release» está marcada.
    • La etiqueta debe tener un prefijo release-.
    • Esto crea una nueva etiqueta anotada. Por ejemplo, release-2019.2beta3
  • Ahora la beta se mostrará en la página de versiones de desarrollo
    • El sistema de actualizaciones automáticas comenzará a ofrecerla a aquellos que busquen betas
  • Haz una revisión del archivo user_docs/en/changes.t2t.
    • Solicita una segunda revisión.

Durante el periodo beta

  • 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.
  • Según se vayan mezclando solicitudes de cambio basadas en la rama beta, crea nuevas etiquetas periódicamente.

Final del periodo beta

  • Tras la beta final, congela las traducciones durante 2 semanas. En este momento no deberían llegar más commits a la rama beta.

Segunda congelación de traducciones

Normalmente no hace falta, pero si se descubre que hay que actualizar las traducciones tras iniciar o completar la congelación de traducciones, entonces:

  • Comprueba que beta tiene los cambios que requieren volver a traducir.
  • Vuelve a hacer los pasos descritos en el documento Iniciar una congelación de traducciones.
  • Envía un correo electrónico a la lista de correo de traducciones describiendo la necesidad de nuevos cambios y plazos.
  • Después de la congelación de traducciones,

Candidatas a liberación

  • Comprueba que es seguro publicar una rc.
    • Mirando las incidencias archivadas recientemente, buscando específicamente las 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
    7. Nota: esto actualiza beta con las nuevas traducciones.
  • Actualiza la rama rc
    • Para la rc1, restablece la rama rc a beta
    • Para la rc1 y posteriores, mezcla beta en rc
  • Comprueba las solicitudes de cambio para rc
    • Busca cualquier solicitud de cambio basada en rc, revísala y aprueba/mezcla o recházala.
  • Crea una nueva pre-release con la página de nueva liberación de GitHub
    • Ejemplo de etiqueta de versión: release-2019.2rc1
    • Destino: rc
    • Ejemplo de título de liberación: Release 2019.2rc1
    • No hace falta descripción para la primera rc, las siguientes rcs pueden describir adiciones o eliminaciones importantes.
    • Asegúrate de que la opción «This is a pre-release» está marcada.
    • La etiqueta debe tener un prefijo release-.
    • Esto crea una nueva etiqueta anotada. Por ejemplo: release-2019.2rc1
  • Espera a que AppVeyor complete la construcción.
    • Al etiquetar la liberación el proceso se dispara automáticamente.
    • Como parte de él, el lanzamiento será efectuado.
  • Publica la liberación efectuada.
    • En exbi, cambia al usuario nvaccess y ejecuta nvdaRelease
  • Difunde la liberación.
    • Crea una entrada de blog en www.nvaccess.org
      • Pon la entrada en la categoría Development. Nunca debería situarse en la categoría News.
    • Usa como base una publicación anterior.
    • Si no es la primera liberación de prueba, incluye los cambios desde la liberación de prueba anterior.
    • Escribe un correo electrónico a la lista nvda-devel
    • Escribe un correo electrónico a la lista nvda-translations
    • Publícala en Twitter
  • Analiza el archivo del instalador
    • Utiliza VirusTotal. Envía la URL de descarga directa.

Liberación final

  • Crea una nueva liberación con la página de nueva liberación de GitHub
    • Ejemplo de etiqueta de versión: release-2019.2
    • Destino: rc
    • Ejemplo de título de liberación: Release 2019.2
    • No hace falta descripción para la liberación final
    • Comprueba que la opción «This is a pre-release» no está marcada.
    • La etiqueta debe tener un prefijo release-.
    • Esto crea una nueva etiqueta anotada. Por ejemplo: release-2019.2
  • Espera a que AppVeyor complete la construcción.
    • Al etiquetar la liberación el proceso se dispara automáticamente.
    • Como parte de él, el lanzamiento será efectuado.
  • Publica la liberación efectuada.
    • En exbi, cambia al usuario nvaccess y ejecuta nvdaRelease
  • Cierra el hito de la liberación.
  • Comprueba que el siguiente hito se ha establecido en incidencias y solicitudes de cambio cerradas ahora automáticamente por GitHub.
    1. Obtén el id del hito para la nueva liberación.
    2. Ve a https://github.com/nvaccess/nvda/milestones
    3. Mira la URL del enlace del hito relevante.
    4. El número al final es el id.
    5. En exbi, edita ~nvaccess/data/nvaServer.conf
    6. En la sección [nvdaGithub], cambia el valor de autoCloseMilestone al identificador del hito que has obtenido en el paso 1.
    7. Recarga uwsgi para que los cambios tengan efecto: sudo systemctl reload uwsgi
  • Difunde la liberación.
    • Crea una entrada de blog en www.nvaccess.org
      • Pon la entrada en la categoría releases.
    • Usa como base una publicación anterior.
    • Escribe un correo electrónico a la lista nvda-devel
    • Escribe un correo electrónico a la lista nvda-translations
    • Publícala en Twitter
    • Publica la noticia en Facebook.
    • Publica la noticia en la lista de correo de noticias de NV Access.
  • Asegúrate de que el número de versión de master y el archivo de cambios están correctos
    1. En source/buildVersion.py, actualiza las variables version_year y/o version_major para la próxima versión.
    2. Si la próxima versión es la primera del año en curso, (por ejemplo, 2018.1), actualiza copyrightYears también.
    3. Añade un encabezado para la siguiente versión en user_docs/en/changes.t2t.
  • Analiza el archivo del instalador
    • Utiliza VirusTotal. Envía la URL de descarga directa.