Las siguientes instrucciones son para el administrador de liberaciones, y detallan cómo liberar una nueva versión oficial.
Consulta la documentación del proceso de liberación para más detalles sobre tiempos.

Liberación beta (liberación previa)

  • 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
  • Haz una revisión del archivo user_docs/en/changes.t2t.
    • Solicita una segunda revisión.
  • Crea una nueva etiqueta anotada / liberación previa.
  • Espera a que AppVeyor complete la construcción.
  • Analiza el archivo del instalador
  • Publica la liberación efectuada.
  • Difunde la liberació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.

Congelación de traducciones

  • Se considera el final del periodo beta después de la liberación de la última beta.
  • Congela las traducciones durante 2 semanas.
    • Llegados a este punto, no se deberían enviar más commits a la rama beta.

Segunda congelación de traducciones

Normalmente no hace falta. Sin embargo, a veces es necesario modificar las cadenas de traducción para resolver una incidencia crítica tras iniciar o completar la congelación de traducciones. Para hacerlo:
* 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.

Candidatas a liberación (liberaciones previas)

  • Comprueba que es seguro publicar una rc.
    • Mirando las incidencias archivadas recientemente, buscando específicamente las etiquetadas como p1, crash o appcrash.
  • Revisa si hay solicitudes de cambio hacia rc, ya que es probable que ocurran después de liberar la primera rc.
  • Si se trata de la rc1, actualiza las traducciones:
    1. Inicia sesión en exbi
    2. Cambia al usuario nvdal10n: sudo su nvdal10n
    3. cd ~/mr/mainNVDACode
    4. mr up
    5. cd ../srt
    6. mr up
    7. mr svn2nvda
      • Esto podría durar unos minutos
      • Busca errores del tipo Unable to push.
    8. Teclea exit para volver a tu propio usuario.
    9. Nota: esto actualiza beta con las nuevas traducciones.
  • Actualiza la rama rc localmente y envía los cambios a GitHub
    • Para la rc1, restablece la rama rc a beta
    • Para la rc1 y posteriores, mezcla beta en rc
  • Crea una nueva etiqueta anotada / liberación previa.
  • Espera a que AppVeyor complete la construcción.
  • Analiza el archivo del instalador
  • Publica la liberación efectuada.
  • Difunde la liberación.

Liberación final

  • Crea una etiqueta anotada / nueva liberación.
  • Espera a que AppVeyor complete la construcción.
  • Analiza el archivo del instalador
  • Publica la liberación efectuada.
  • Difunde la liberación.
  • 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. Inicia sesión en exbi
    6. Cambia al usuario nvaccess: sudo su nvaccess
    7. Edita ~nvaccess/data/nvaServer.conf
    8. En la sección [nvdaGithub], cambia el valor de autoCloseMilestone al identificador id del hito que has obtenido en el paso 1.
    9. Guarda el archivo y teclea exit para volver a tu propio usuario.
    10. Recarga uwsgi para que los cambios tengan efecto: sudo systemctl reload uwsgi
  • En el código de NVDA, asegúrate de que el número de versión de la rama 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 si todavía no existe.

Crear la liberación / etiqueta anotada

  • Haz checkout de la versión a liberar.
    • git fetch
  • git checkout origin/<rama>
  • Donde <rama> es:
    • Para una beta: beta
    • Para una RC: rc
    • Para una liberación: rc
  • Crea una nueva etiqueta anotada en Git, y envíala a GitHub.
  • Crear etiqueta: git tag -a <nombre de etiqueta> -m "<mensaje>"
    • La etiqueta debe tener un prefijo release-. Por ejemplo:
      – Beta: Release-2019.2beta3
      – Rc: Release-2019.2rc1
      – Liberación: Release-2019.2
    • La primera línea del mensaje debería contener el título de la liberación. Por ejemplo:
      – Beta: Release 2019.2beta3
      – Rc: Release 2019.2rc1
      – Liberación: Release 2019.2
    • El mensaje puede contener información extra (dejando una línea en blanco) relevante para esta liberación en concreto.
  • Envía a GitHub: git push origin <nombre de etiqueta>
    • Al etiquetar la liberación se dispara automáticamente la compilación en appveyor, como parte de esto se efectuará la liberación.
    • Ahora la liberación se mostrará en la página de versiones de desarrollo (bajo beta o rc)
    • El sistema de actualizaciones automáticas comenzará a ofrecerla a aquellos que busquen betas
  • Convierte la etiqueta anotada en una nueva liberación de GitHub con la página de nueva liberación de GitHub
  • Haz clic en el botón de menú tag, mostrado como «…», y elige «Create release»
    • Ejemplo de título de liberación: Release 2019.2beta3,
    • No hace falta descripción para la primera beta / rc / liberación, en las siguientes betas / rc / liberaciones se pueden describir adiciones o eliminaciones importantes.
    • Si es una versión rc o beta, asegúrate de que la opción «This is a pre-release» está marcada.

Razonamiento

Las «releases» de GitHub tienen un formato diferente, pueden incluir metadatos como ‘pre-release’ y pueden tener binarios adjuntos. En el futuro, a NV Access le gustaría migrar a un sistema más automatizado que cree las liberaciones desde el script de Appveyor y adjunte los binarios. Por desgracia, las liberaciones de GitHub no crean una «etiqueta anotada» en Git, por lo que la etiqueta para la liberación no dispone de fecha o mensaje.

Analiza la compilación

  • Utiliza VirusTotal.
  • Simplemente envía la URL de descarga del artefacto de appveyor
  • Recientemente, usar la URL de Appveyor ha dado como resultado una incidencia («CRDF») en uno de los 72 analizadores.
  • Continúa analizando con la URL de NV Access, ya que el analizador «CRDF» no la identifica como problemática.

Publica la liberación efectuada

  • Conéctate a exbi
  • Cambia al usuario nvaccess: sudo su nvaccess
  • Ejecuta nvdaRelease
  • Esto confirmará el fichero actualmente almacenado.

Difunde la liberación

  • Crea una entrada de blog en www.nvaccess.org
    • Usa como base una publicación anterior.
  • Usa un enlace al archivo en NVAccess.org, los artefactos de compilación de Appveyor caducan tras seis meses.
    • Para rc y beta: pon la entrada en la categoría development.
    • Excluyendo la primera liberación de prueba, incluye los cambios desde la liberación de prueba anterior.
    • Para la versión final: pon la entrada en la categoría releases.
    • Nunca debería situarse en la categoría News.
  • Publica en la lista nvda-devel
  • Publica en 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.